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

From:		Daniel Phillips <phillips@arcor.de>
To:		Ed Sweetman <ed.sweetman@wmich.edu>, Eugene Teo <eugene.teo@eugeneteo.net>
Subject:		Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches
Date:		Sun, 27 Jul 2003 10:46:30 -0500
Cc:		LKML <linux-kernel@vger.kernel.org>, kernel@kolivas.org

On Saturday 26 July 2003 06:24, Ed Sweetman wrote:
> I'd really wish people would use examples other than a single player to
> generalize the performance of the kernel. For all you know xmms's
> decoder for the type of music you listen to could be written unoptimally
> to put it as nice as possible.  If all players and different types of
> pcm audio decoders are skipping in the situations you experience then
> that's different, but i hardly think that will be the case as it is not
> with me nor, ever has been that i can remember (maybe in early 2.3.x).

Audio players fall into a special category of application, the kind where it's 
not unreasonable to change the code around to take advantage of new kernel 
features to make them work better.  Remember this word: audiophile.  An 
audiophile will do whatever it takes to attain more perfect reproduction.  
Furthermore, where goes the audophile, soon follows the regular user.  Just 
go into a stereo store if you need convincing about that.

Now to translate this into concrete terms.  Audio reproduction is a realtime 
task - there is no way to argue it's not.  Ergo, perfect audo reproduction 
requires a true realtime scheduler.  Hence we require realtime scheduling.

The definition of a realtime scheduler is that the worst case latency is 
bounded.  The current crop of interactive tweaks do not do that.  So we need 
a scheduler with a bounded worst case.  Davide Libenzi's recent patch that 
implements a new SCHED_SOFTRR scheduler policy, usable by non-root users, 
provides such a bound.  Please don't lose sight of the fact that this is the 
correct solution to the problem, and that interactive tweaking, while it may 
produce good results for some or even most users in some or even most 
situations, will never magically transform Linux into an operating system 
that an audiophile could love.

Note: none of the above should be construed as discouragement for Con's work 
on improving interactive performance.  Just don't lump audio playback into 
the "interactive" category, please, it's not.  It's realtime.  By keeping 
this firmly in mind we will end up with better interactive performance, 
excellent audio reproduction, and simpler, better code overall.

Another note: I have not tested Davide's patch, nor have I read it in detail, 
or Ingo's scheduling code for that matter.  For that I plead "road trip". 
I'll do all of the above as soon as I get back to Berlin.  I do know that the 
Linux Audio guys I talked to at Linuxtag are excited about Davide's patch, 
and think it's exactly the right way to go.

Regards,

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

(Log in to post comments)

Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches

Posted Jul 31, 2003 12:50 UTC (Thu) by beejaybee (guest, #1581) [Link]

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).

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.

Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches

Posted Aug 1, 2003 20:31 UTC (Fri) by iabervon (subscriber, #722) [Link]

It seems to me that there is a characteristic pattern of processor and I/O usage that will determine soft realtime tasks, and, like interactivity, it should be automatically detected by the kernel. Certainly any task which sleeps after writing to an audio device should be woken as soon as the sleep timer expires, and similarly for any device with a buffer which is written out at a fixed rate, with some effect to the buffer becoming empty.