lkml.org 
[lkml]   [2009]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Is adding requeue_delayed_work() a good idea
Roland Dreier wrote:
[Oleg Nesterov wrote]
> Perhaps the semantics are sufficiently fuzzy and not general enough, so
> that the best answer is my special-case open coded change for my
> specific case. I don't know whether other places would even want a
> requeue_delayed_work() ... I simply raise this point because when I find
> myself reimplementing the structure of work_struct + timer because
> delayed_work API is lacking, then it seems prudent to consider extending
> delayed_work API instead.

There are two or three use cases of rescheduling a delayed work in
drivers/firewire, but in one regard they are simpler than your case:

The work only needs to be pushed back in time, never scheduled earlier
than it was originally scheduled. This is easily implemented with the
existing delayed work API by letting the work check whether it is
entered too early; if yes, reschedule itself.

Further requirements of this use case:
- It doesn't matter on which CPU this kind of work runs on.
- If the event which necessitates rescheduling happens when the
work is already running, then it might depend on the outcome of
the work whether it needs to be scheduled again. I think the
requeue_delayed_work should do nothing in that case and the
work needs to test how it went and rearm if necessary.

Well, considering the latter point, there is no harm in keeping all of
the requeue_delayed_work logic concentrated in the work itself in these
FireWire use cases.

[These use cases are high-level protocols for resource acquisition over
the FireWire bus. Cooperative fairness schemes require them to be timed
after a grace period for resource re-acquisition by holders of older
resources, following after bus reset events which may happen any time.]

So, the question is whether there is any user besides IB which needs to
pull a delayed work forward in time.

Or another thought: Would it hurt if you ignored any shortening of
timeouts, i.e. reduce your use case also to only ever _deferring_ work,
never rescheduling to an earlier point in time?
--
Stefan Richter
-=====-==--= =--- =-==-
http://arcgraph.de/sr/


\
 
 \ /
  Last update: 2009-08-22 12:39    [W:1.590 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site