Re: Is adding requeue_delayed_work() a good idea

[Stefan Richter]

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/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/