Re: Ingo Molnar and Con Kolivas 2.6 scheduler patches

[Daniel Phillips <phillips@arcor.de>]

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