Re: [RFC] schedule_timeout_range()

[David Woodhouse]

On Tue, 2008-07-22 at 14:50 +1000, Nick Piggin wrote:
> On Tuesday 22 July 2008 14:45, David Woodhouse wrote:
> > On Tue, 2008-07-22 at 14:33 +1000, Nick Piggin wrote:
> > > The only thing I dislike about explicit times is that when a driver or
> > > someone doesn't _really_ know how much to specify. Do you say 10s, 100s?
> >
> > This is true, but they certainly have a _better_ idea than we do. If the
> > individual callers can't even come up with an answer, how are we ever
> > going to come up with a generic policy that does the right thing?
> 
> OK, how about still having a never-until-machine-is-already-awake?

For timers we have that already -- it's called a deferrable timer. All
I've done to create the 'range timer' is couple that with a normal
timer, to implement the 'some time between X and Y' behaviour in a
fashion which is simple for people to use.

I did add the 'never-until-machine-is-already-awake' behaviour you
request to schedule_timeout_range() -- you get it by setting 'timeout'
to your intended minimum time, and setting the other argument (which was
called 'deadline' in my original patch) to MAX_SCHEDULE_TIMEOUT.

> > I really don't think that applying this kind of policy in generic code
> > is useful -- I'd like the callers to provide numbers even if they _do_
> > pull it out of their wossname.
> >
> > The number they provide is the _maximum_ amount of time they should be
> > prepared to wait (let's assume for a moment that they stayed sober and
> > remembered Linux isn't a real-time kernel, so all guarantees are taken
> > with a pinch of salt. Let's not get bogged down in nomenclature).
> 
> Well, I think it is still wise to avoid words like deadline, hard,
> and timeout in the same sentence ;)

Probably true :)

> > In practice, they'll almost always get called before that maximum time
> > expires -- that's the whole _point_, of course. But we can't _invent_
> > that maximum in generic code; that's really up to the caller.
> 
> Not a maximum, but just an "I don't know... a lot?" define. But yeah
> I guess there aren't too many good reasons for that.

I'd really like to avoid it. It puts the responsibility for coming up
with a number a _long_ way from where it should be, in the individual
caller.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@xxxxxxxxx                              Intel Corporation


--
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/