mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@tv-sign.ru>
To: Jarek Poplawski <jarkao2@o2.pl>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Chinner <dgc@sgi.com>, David Howells <dhowells@redhat.com>,
	Gautham Shenoy <ego@in.ibm.com>, Ingo Molnar <mingo@elte.hu>,
	Srivatsa Vaddagiri <vatsa@in.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] make cancel_rearming_delayed_work() reliable
Date: Tue, 8 May 2007 18:05:17 +0400	[thread overview]
Message-ID: <20070508140517.GA1105@tv-sign.ru> (raw)
In-Reply-To: <20070508135648.GG1772@ff.dom.local>

On 05/08, Jarek Poplawski wrote:
>
> On Tue, May 08, 2007 at 04:31:02PM +0400, Oleg Nesterov wrote:
> > 
> > I thought about adding such a parameter, and I don't like this. This is
> > a matter of taste, of course, but _imho_ this uglifies the code.
> > 
> > In any case, unless we do completely different patch, the sequence should be
> > 
> > 	del_timer()	- a pending timer is the most common case
> > 
> > 	test_and_set_bit(WORK_STRUCT_PENDING) - the work is idle
> > 
> > 	try-to-steal-the-queued-work
> > 
> > This is what we are doing now.
> 
> I simply don't like to call del_timer(), where not needed, but maybe
> it's not so expensive and we can afford it... 

But this is the most common case, that was my point.

Look, we can add

	if (!get_wq_data(work))
		/* it was never queued */
		return;

at the very start of cancel_xxx() functions. This will optimize out
del_timer + try_to_grab_pending() _sometimes_. Should we do this?
I don't think so. I think it is better to save a couple of bytes
from i-cache, but not to try to optimize the unlikely case.

> > 
> > > > +
> > > > +	/*
> > > > +	 * The queueing is in progress, or it is already queued. Try to
> > > > +	 * steal it from ->worklist without clearing WORK_STRUCT_PENDING.
> > > > +	 */
> > > > +
> > > > +	cwq = get_wq_data(work);
> > > > +	if (!cwq)
> > > > +		return ret;
> > > 
> > > Probably you meant:
> > > 		return 1;
> > 
> > No, we should return 0. This can happen if the queueing of the freshly-
> > initialized @dwork is in progress.
> > 
> > NOTE: right now try_to_grab_pending() is called from cancel_xxx() only, so
> > this can't happen (it would be meaningless to do cancel_xxx if somebody else
> > can queue this work or start the timer), but I'd like try_to_grab_pending()
> > to be as generic as possible.
> > 
> > So, we should either return 0, or add BUG_ON(!cwq).
> 
> ...And you prefer endless loop. Seems brave!

No, no, the loop won't be endless. Why do you think so? We spin until the timer
is started, or until the work is queued.

Oleg.


  reply	other threads:[~2007-05-08 14:05 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-03 20:42 Oleg Nesterov
2007-05-04  1:15 ` Andrew Morton
2007-05-04 17:09   ` Oleg Nesterov
2007-05-05 21:32   ` [PATCH] make-cancel_rearming_delayed_work-reliable-fix Oleg Nesterov
2007-05-07 10:31     ` Jarek Poplawski
2007-05-07 10:34       ` Oleg Nesterov
2007-05-07 11:55         ` Anton Vorontsov
2007-05-07 11:33           ` Oleg Nesterov
2007-05-08  9:16         ` Jarek Poplawski
2007-05-08 12:02           ` Oleg Nesterov
2007-05-08 13:07             ` Jarek Poplawski
2007-05-08  7:15 ` [PATCH] make cancel_rearming_delayed_work() reliable Jarek Poplawski
2007-05-08 12:31   ` Oleg Nesterov
2007-05-08 13:56     ` Jarek Poplawski
2007-05-08 14:05       ` Oleg Nesterov [this message]
2007-05-08 14:32         ` Jarek Poplawski
2007-05-08 14:12       ` Jarek Poplawski
2007-05-11 13:55 ` Tejun Heo
2007-05-11 13:47   ` Oleg Nesterov
2007-05-11 15:19     ` Tejun Heo
2007-05-11 14:53       ` Oleg Nesterov
2007-05-12  5:50         ` Tejun Heo
2007-05-13 19:27           ` Oleg Nesterov
2007-05-13 20:16             ` Tejun Heo
2007-05-13 21:25               ` Oleg Nesterov
2007-05-14 19:44               ` Oleg Nesterov
2007-05-15  8:26                 ` Tejun Heo
2007-05-15 13:09                   ` Jarek Poplawski
2007-05-15 22:08                     ` Oleg Nesterov
2007-05-16  5:21                       ` Jarek Poplawski
2007-05-15 22:00                   ` Oleg Nesterov
2007-05-16 11:25                     ` Tejun Heo
2007-05-16 18:52                       ` Oleg Nesterov
2007-05-17  9:36                         ` Tejun Heo
2007-05-18  7:35                         ` Jarek Poplawski
2007-05-18  8:13                           ` Jarek Poplawski
2007-05-18 13:33                           ` Tejun Heo
2007-05-21  7:00                             ` Jarek Poplawski
2007-05-21  8:59                               ` Tejun Heo
2007-05-21 10:10                                 ` Jarek Poplawski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070508140517.GA1105@tv-sign.ru \
    --to=oleg@tv-sign.ru \
    --cc=akpm@linux-foundation.org \
    --cc=dgc@sgi.com \
    --cc=dhowells@redhat.com \
    --cc=ego@in.ibm.com \
    --cc=jarkao2@o2.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=vatsa@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®