On 05/03, Andrew Morton wrote:
>
> On Fri, 4 May 2007 00:42:26 +0400
> Oleg Nesterov <[email protected]> wrote:
>
> > Disadvantages:
> >
> > - this patch adds wmb() to insert_work().
> >
> > - slowdowns the fast path (when del_timer() succeeds on entry) of
> > cancel_rearming_delayed_work(), because wait_on_work() is called
> > unconditionally. In that case, compared to the old version, we are
> > doing "unneeded" lock/unlock for each online CPU.
> >
> > On the other hand, this means we don't need to use cancel_work_sync()
> > after cancel_rearming_delayed_work().
> >
> > - complicates the code (.text grows by 130 bytes).
> >
>
> hm, this is getting complex.
Yes, and I can't say I like this patch very much.
First, I am not really sure it is terribly useful. Yes, cancel_rearming_delayed_work
sucks, but did we have any problem in practice? The most annoying problem is that it
cant't cancel @dwork which doesn't re-arm itself unconditionally. But this is not so
common, and ata_port_flush_task() shows an example how to do this. However, it also
shows that this is not so trivial, and work->func() should participate.
Also, we can solve this problem in more simple way. For example, we can shift
"timer->function = delayed_work_timer_fn" from queue_delayed_work() to INIT_DELAYED_WORK().
Then, roughly,
cancel_rearming_delayed_work(dwork)
{
dwork->timer->function = do_nothing_timer_fn;
del_timer_sync(&dwork->timer);
wait_on_work(&dwork->work);
dwork->timer->function = delayed_work_timer_fn;
del_timer(&dwork->timer);
work_clear_pending(&dwork->work
}
But this is so hackish, and doesn't work if work->func() use queue_work() or
queue_delayed_work(delay = 0) to re-arm itself. Perhaps we can forbid this,
and make a simpler patch.
> > + while (!try_to_grab_pending(work))
> > + ;
>
> The patch adds a couple of spinloops. Normally we put a cpu_relax() into
> such loops. It can make a very large difference under some circumstances.
Ah, yes. I'll send a fix along with a little comments update.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
