Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches [LWN.net]

Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches

Posted Jul 31, 2003 12:50 UTC (Thu) by beejaybee (guest, #1581)
Parent article: Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches

Yes, Daniel is so obviously right. Same applies to multimedia playback.

The problem here is that some morons will undoubtedly use any scheduling hooks intended for genuine real-time applications where there is no need to do so, except to improve the benchmark performance of their product. Result, when everyone uses real-time scheduling, audio is _still_ broken.

To make this work properly you need a double constraint: as well as guaranteeing maximum latency, you need a guarantee that real-time processes cannot totally exclude interactive processes. This implies two things: (a) every so often, interactive processes which are not expiring their timeslice should be boosted temporarily so that they get one timeslice at real-time priority to guarantee them access to the CPU; (b) timeslice should be dependent on priority, with longer timeslices for compute-bound processes (which will usually be pre-empted by interactive or real-time process events) and very short timeslices for real-time processes (so that the task switching mechanism overheads discourage overuse of real-time priority).

(Log in to post comments)

Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches

Posted Aug 1, 2003 17:54 UTC (Fri) by graydon (subscriber, #5009) [Link]

I don't know about this particular implementation of soft realtime, but in theory it's not necessarily true that soft realtime would improve throughput-oriented benchmarks.

the soft realtime means when I sleep (or get preempted) I can get a precise idea of how long in real time it'll be until I run again. it doesn't mean I'll necessarily run for very long, nor frequently, just that there'll be some accuracy in the accounting. I need that accuracy to work out buffer sizes and decoding rates for a media player; I don't necessarily need high CPU throughput. xmms doesn't usually eat more than a fraction of a percent of my CPU.

if I'm given longer, but more random and imprecise timeslices, I might actually do better if I'm a long-lived, non-interactive process. precision might only be achieved at the expense of throughput.