Yes I see. But actually I meant "see below, I don't think we need
Exactly! And in that case update_timer_expiry() will do its work.
Yes, the games with __queue_delayed_work() can save a couple of clear/set
bit, but this is the slow an unlikely path, that was my point.
And, if we are talking about the function call overhead. Please note
that __queue_delayed_work() adds the "unnecessary" call to the "normal"
queue_delayed_work(), and this path is more common.
Hmm. How so? cancel() always cancells the work.
OK, let's suppose we have
cancel_delayed_work(dwork);
queue_delayed_work(dwork, delay);
and now (the next patch you sent) we turn this code into
queue_update_delayed_work(dwork, delay);
Now we have a subtle difference which _may_ be important for some users.
Suppose that this dwork was queued before, the timer has expired, and
now cwq->thread runs dwork->work->func(). Note that this dwork is not
pending (WORK_STRUCT_PENDING is cleared).
Before the change above, cancel_delayed_work() waits until work->func()
completes, then we re-queue the work.
After the change, the fast path just queues the same dwork again.
If the workqueue is not singlethreaded, it is possible that both
old and new "instances" will run on the different CPUs at the same
time.
No.
dwork is not pending, L is a lower priority thread, H - real time.
L calls queue_update_delayed_work(), and sets WORK_STRUCT_PENDING
successfully(). It is going to do __queue_delayed_work(), but it
is preempted by H.
H does queue_update_delayed_work(), WORK_STRUCT_PENDING is already
set and the timer is not pending. Now it will do try_to_grab_pending()
Yes. I must admit, I prefer the simple, non-intrusive code I suggested
much more.
Once again, the slow path is (at least, supposed to be) unlikely, and
the difference is not that large. (I mean the slow path is when both
queue() and update_timer() fail).
Should we complicate the code to add this minor optimization (and
btw pessimize ...
