Re: [PATCH] push rounding up of relative request to schedule_timeout()

[Nishanth Aravamudan <nacc@us.ibm.com>]

On 04.08.2005 [20:59:50 +0200], Roman Zippel wrote:
> Hi,
> 
> On Thu, 4 Aug 2005, Nishanth Aravamudan wrote:
> 
> > The comment for schedule_timeout() claims:
> > 
> >  * Make the current task sleep until @timeout jiffies have
> >  * elapsed.
> > 
> > Currently, it does not do so. I was simply trying to make the function
> > do what it claims it does.
> 
> What makes you think the comment is correct? This comment was added at 
> 2.4.3, while schedule_timeout() has this behaviour since it was added at 
> 2.1.127.

Fair enough. Should we change the comment? What are the expectations of
programmers wrt. to this interface?

> > My point was that the +1 issues (potential
> > infinite timeouts) are a problem with *jiffies* not milliseconds. And
> > thus need to be pushed down to the jiffies layer. I think my explanation
> > was pretty clear.
> 
> Not really, could you go into more details why it's "a problem with 
> *jiffies* not milliseconds"?

Well, I may have phrased that wrong. It's not that milliseconds in the
kernel wouldn't have the same problem -- they would/do, because they
convert to jiffies eventually.

This is all the same issue, as George pointed out, that itimers face.

If a user requests schedule_timeout(HZ/100); which, if HZ is 1000, is 10
jiffies, yes? But, since we are between ticks, we want to actually add
that request to the next interval, not to the current one. Otherwise, we
do have the possibility of returning early. Currently, we require
callers to add the +1 to their request, and thus they only add it to the
first one. The problem with my patch which pushed it to
schedule_timeout(), is that we will do +1 to every request. I'm not
sure, without some sort of "persistent" timeout control structure, how
we get around that, though, in the schedule_timeout() case. Does that
make any more sense?

Thanks
Nish