lkml.org 
[lkml]   [2003]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Ingo Molnar and Con Kolivas 2.6 scheduler patches
    Date
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:47    [W:3.339 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site