On Mon, Mar 17, 2014 at 7:40 AM, Tejun Heo [off-list ref] wrote:

Hello,

On Sun, Mar 16, 2014 at 12:13:55PM -0700, dbasehore . wrote:

quoted

There's already behavior that is somewhat like that with the current
implementation. If there's an item on a workqueue, it could run at any
time. From the perspective of the driver/etc. that is using the
workqueue, there should be no difference between work being on the
workqueue and the kernel triggering a schedule right after the work is
removed from the workqueue, but before the work function has done
anything.

It is different.  mod_delayed_work() *guarantees* that the target work
item will become pending for execution at least after the specified
time has passed.  What you're suggesting removes any semantically
consistent meaning of the API.

It will still be at least be pending after the specified time has
passed. I'm proposing that we still set the timer. The difference is
that there is a possibility the work will already be pending when the
timer goes off. There will still at least be an execution after the
given time has past. We could still remove the work in the workqueue
from the timer function, but this would make the mod_delayed_work not
race with any work that was scheduled for immediate execution
previously.

If you make the timer function remove any pending work from the
workqueue when the timer goes off, this is still following the API.
The work will still become pending at least after the specified time
has passed.

quoted

So to reiterate, calling mod_delayed_work on something that is already
in the workqueue has two behaviors. One, the work is dispatched before
mod_delayed_work can remove it from the workqueue. Two,
mod_delayed_work removes it from the workqueue and sets the timer (or
not in the case of 0). The behavior of the proposed change should be
no different than the first behavior.

No, mod_delayed_work() does *one* thing - the work item is queued for
the specified delay no matter the current state of the work item.  It
is *guaranteed* that the work item will go pending after the specified
time.  That is the sole meaning of the API.

quoted

This should not introduce new behavior from the perspective of the
code using delayed_work. It is true that there is a larger window of
time between when you call mod_delayed_work and when an already queued
work item will run, but I don't believe that matters.

You're completely misunderstanding the API.  Plesae re-read it and
understand what it does first.

Thanks.

--
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>