lkml.org 
[lkml]   [2008]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/5] select: make select() use schedule_hrtimeout()
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)



\
 
 \ /
  Last update: 2008-08-29 18:33    [W:0.497 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site