Re: [PATCH 4/5] select: make select() use schedule_hrtimeout()

[Arjan van de Ven <arjan@infradead.org>]

On Fri, 29 Aug 2008 09:20:18 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Fri, 29 Aug 2008, Arjan van de Ven wrote:
> > 
> > now that we have schedule_hrtimeout(), make select() use it.
> > But only for short delays; really long delays are assumed to not
> > need the highres level of accuracy but rather want the regular
> > timer behavior for now.
> 
> This is _really_ ugly.
> 
> Can't you just do this relaxation in "schedule_hrtimeout()" instead,
> and just document the fact that the "high resolution" of hrtimeout is
> relative to the length of the timeout.

yes we can
(sorry, bad pun)
 
> It's not that select() doesn't care, it's that *NOBODY* cares. If
> somebody asks for a timeout of one second and 2 microseconds, the two
> microseconds simply don't matter. Ever. But if somebody asks for a
> timeout of 12 microseconds, individual microseconds probably _do_
> matter.

ok I'll do it this way; I wanted to avoid changing behavior for long
delays (some people think there's too much overhead in hrtimers or
something) but i'm totally fine with not doing this bifurbicated
braintwist at all.

> 
> So if you want high-resolution select/poll, then get rid of the
> "use_hr" logic entirely, and just do it unconditionally. Then, relax
> the scheduler timeouts in the scheduler.

ok, no big deal, see below

> 
> (But, that's probably _generally_ true. Even now, when people do 
> "schedule_timeout()", there's a big difference between asking for two 
> ticks and asking for two seconds. The latter should probably try to
> round to a nice timer tick basis for power reasons).

yes that's a separate story; this is what "range timers" are about and
David Woodhouse and I are working on that as well
(but this select stuff is basically a prerequisite to use that)