God no. But if there's some way for the OS to tell the app how long it's
timeslice is going to be each time it schedules it, then you can do
interesting things.
Consider an OS which doesn't just preempt and return control later, instead it
returns control to the same point in a process each time it schedules it -
with a register set with an estimate of how long the process is going to keep
the CPU. The process can then return to where it was (special form of
longjmp?) or start again (rendering a new frame instead of finishing the one
that's now too old anyway).
This is the kind of thing that I was referring to, and it's not likely to
happen in Linux any time soon.
> Note that this won't work "fine". If there is nothing "realtime"
> running, and I ask the OS: what percentage of the CPU do you have
> available? I'm going to get the answer: "100%". If I then use (close
> to) 100%, the X server for instance will be starved. Kind of useless
> mpeg player then. So the developer decides that if the OS says 100%,
> he will request 90%. Fine. Now someone else has a system where the X
> server requires significantly more CPU horsepower to display the same
> stream. Now what?
If you use all that's available, and react dynamically to the actual amount
you're getting, rendering at lower quality when you're getting smaller
timeslices, and rendering at higher quality when you're getting more CPU, then
you can do fairly clever things. Without setting realtime priority and
starving the other processes.
> Conclusion: The "ask the OS for a guaranteed percentage of the CPU"
> sysstem isn't all that easy to use anyway....
None of it is easy to use. It's a difficult problem.
---- ---- ----
David Woodhouse David.Woodhouse@mvhi.com Office: (+44) 1223 810302
Project Leader, Process Information Systems Mobile: (+44) 7976 658355
Axiom (Cambridge) Ltd., Swaffham Bulbeck, Cambridge, CB5 0NA, UK.
finger dwmw2@ferret.lmh.ox.ac.uk for PGP key.
-
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/