Re: [PATCH] 'select' failure or signal should not update timeout

[Jamie Lokier]

Eric W. Biederman wrote:
> When we have a cpu load average < 1, it is trivial to increase the
> timer granularity to something resembling the gettimeofday resolution 
> simply by internally doing gettimeofday when schedule is called, and
> adding those processes that have just become runnable to the run
> queue.  To get the most out of this the idle task would need to busy
> wait looking for timer events, when we have an event scheduled before
> the next timer tick.

Unfortunately, this does not help "soft real-time" tasks like the
hypothetical video game with a compile running in the background.  That
needs to preempt lower priority tasks somehow.

Ideally, because they don't use much CPU but do want to run on time, it
should be possible to run those programs using non-real-time priority,
and they would run on time simply because they always have a high
dynamic priority.

To be fair, although 100Hz timer resolution wasn't good enough even for
a simple "snake" video game with no other load (the eye detects the time
variance as an apparent velocity variance), 1000Hz is probably fine.

> The goal is twofold, to remove the need for user space applications to
> busy wait, so sometimes the system can get something done another
> process is waiting, and to increase the internal kernel timer
> granularity to the point where user space doesn't care anymore.  With
> the only timer we sleep past the desired time is when the kernel
> decides there is some higher priority task to run.

What will happen if the timer granularity remains at 1000Hz when
loadavg > 1 is that time-sensitive interactive apps will still busy wait
for the remainder of a tick.  _But_, if we can define select() or similar
semantics to mean, as Linus suggested, "wait until at most TIME", then
it becomes possible to avoid the busy wait at low loads (paradoxically).

> The most interesting use I have seen is a high performance local area
> data transfer utility, that would do short sleeps in between sending
> packets to avoid pushing the switch to the point where it would drop
> packets.  But it was perfectly fine if a new packet came in before it
> was done waiting for the old packet to go out the wire.

That's the sort of thing I work on :)  The resolution required of a
packet shaper is measured in 10s of microseconds, though, so I just
accept that user space must busy wait _all_ the time the link isn't idle.

-- Jamie