> Steve Underwood wrote:
> > Basically what this type of application needs is regular repetitive
> > scheduling. A "wake me up at XXHz intervals" facility would make a
> > lot of these types of applications smooth and efficient.
>
> I would imagine making select() accurate (or some other call)
> would be just as easy and far more generally useful.
The whole point is you can't make select _extremely_ accurate, unless the
machine is idle. Any machine activity has the potential to make screen
updates stutter. Stuttering is _very_ bad for the perceived visual quality
of motion. Most visual flow things look far better if you miss the odd
frame update, but get the ones that do occur to happen exactly on time.
That way a short term machine overload causes just a hiccup in the flow.
Select will always cause visually unpleasant jitter, even if its timing is
much better than today's.
> > You would need some complexity to deal with a heavily loaded
> > machine. I think simply skipping some scheduling events on a loaded
> > machine would give the most tolerable result for most applications. In
> > this case it would help the application if it were informed how many
> > scheduling events have been missed since the last scheduling.
>
> gettimeofday() is good enough for this.
"Good enough" isn't good enough. When the next scheduling occurs after a
missed event, the schedular would already know an event was missed. It
might as well tell the app. and avoid a wasteful call to gettimeofday.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/