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

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

On Fri, 29 Aug 2008 10:26:02 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Fri, 29 Aug 2008, Alan Cox wrote:
> >
> > > "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).
> > 
> > I disagree - that is fixing the problem in the wrong place. The
> > timer structure needs an accuracy field of some form that the
> > existing timer functions initialise to 0.
> 
> I do agree that we could do that too, but you miss one big issue:
> even if we were to add an accuracy field inside the kernel, there is
> no such field in the user interfaces.
> 
> We just pass timevals (and sometimes timespecs) around, and no, they
> don't have any way to specify accuracy.
> 
> Yeah, we could use the high bits in the usec/nsec words, but then
> older kernels would basically do random things, so that would be a
> horrible interface.
> 
> The other thing to do would be to just add totally new system calls
> with totally new interfaces, but (a) nobody would use them anyway and
> (b) it's simply not worth it.
> 
> So given that reality, and _if_ we want to support nice
> high-resolution sleeping by select/poll, the only reasonable thing to
> do is to estimate some kind of expected accuracy from the existing
> timeval/timespec.
> 
> And the only reasonable way to do that is to just look at the range.
> You can probably do something fairly trivial with


that works

one of the things we were thinking about was to also have a field in
the task struct (so inherited over fork/exec) that is the default
"slack", which can be set via a prctl, so that an admin can do a "nice"
like thing and run certain known silly apps at different granularity
(and a bunch of smart tricks in some key apps that we'll then do)



-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org