lkml.org 
[lkml]   [2003]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux 2.6.0-test6


    Pedro Larroy wrote:

    >On Mon, Sep 29, 2003 at 12:55:12PM -0400, Ed Sweetman wrote:
    >
    >>Nick Piggin wrote:
    >>
    >>>
    >>>Rob Landley wrote:
    >>>
    >>>
    >>>>On Sunday 28 September 2003 02:03, Con Kolivas wrote:
    >>>>
    >>>>
    >>>>>On Sun, 28 Sep 2003 11:27, Linus Torvalds wrote:
    >>>>>
    >>>>>>from Andrew Morton. Most notably perhaps Con's scheduler changes that
    >>>>>
    >>>>>>have been discussed extensively and made it into the -mm tree for
    >>>>>>testing.
    >>>>>>
    >>>>>>
    >>>>>For those who are trying this for the first time, please note that the
    >>>>>scheduler has been tuned to tell the difference between tasks of the
    >>>>>_same_
    >>>>>nice level. This means do NOT renice X or it will make audio skip unless
    >>>>>you also renice your audio application by the same amount. Lots of
    >>>>>distributions have done this for the old 2.4 scheduler which could not
    >>>>>treat equal "nice" levels as differently as the new scheduler does
    >>>>>and 2.6
    >>>>>shouldn't need special treatment.
    >>>>>
    >>>>>So for testing note the following points:
    >>>>>
    >>>>>Make sure X is NOT reniced to -10 as many distributions are doing.
    >>>>>Some shells spawn processes at nice +5 by default and this will make
    >>>>>audio
    >>>>>apps suffer.
    >>>>>Make sure your hard disk, graphics card and audio card are performing at
    >>>>>equal standard to your 2.4 kernel (ie dma is working, graphics is fully
    >>>>>accelerated etc).
    >>>>>
    >>>>>
    >>>>I.E. with your new scheduler, priority levels actually have enough of
    >>>>an effect now that things that aren't reniced can be noticeably
    >>>>starved by things that are.
    >>>>
    >>>>
    >>>AFAIK, Con's scheduler doesn't change the nice implementation at all.
    >>>Possibly some of his changes amplify its problems, or, more likely they
    >>>remove most other scheduler problems leaving this one noticable.
    >>>
    >>>If X is running at -20, and xmms at +19, xmms is supposed to still get
    >>>5% of the CPU. Should be enough to run fine. Unfortunately this is
    >>>achieved by giving X very large timeslices, so xmms's scheduling latency
    >>>becomes large. The interactivity bonuses don't help, either.
    >>>
    >>>
    >>there are 40 positions between -20 and 19, that doesn't equal 5% steps.
    >>They don't even refer to % of cpu. If i nice a process to -20 it
    >>doesn't get a given percentage of cpu just because it's -20. I may have
    >>other processes at -20 as well. If you nice something to -20 and it is
    >>actually using that cpu then things that are +19 shouldn't run and wont
    >>run. If I nice -20 vmstat 1, it's not going to starve xmms (or any
    >>better audio player). -20 means starve all and it should do that when
    >>it actually makes use of the resources.
    >>
    >>
    >
    >Why not run xmms with SCHED_RR or SCHED_FIFO?
    >
    >

    Well because playing an mp3 really is a pitiful task for modern CPUs,
    and the standard scheduler should handle this fine. Also a music skip
    isn't terribly important.

    Realtime applications are difficult to make robust and they can easily
    hang the system.

    -
    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:49    [W:4.470 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site