[lkml]   [2007]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [REPORT] cfs-v4 vs sd-0.44
    On Sunday 22 April 2007 02:00, Ingo Molnar wrote:
    > * Con Kolivas <> wrote:
    > > > Feels even better, mouse movements are very smooth even under high
    > > > load. I noticed that X gets reniced to -19 with this scheduler.
    > > > I've not looked at the code yet but this looked suspicious to me.
    > > > I've reniced it to 0 and it did not change any behaviour. Still
    > > > very good.
    > >
    > > Looks like this code does it:
    > >
    > > +int sysctl_sched_privileged_nice_level __read_mostly = -19;
    > correct.

    Oh I definitely was not advocating against renicing X, I just suspect that
    virtually all the users who gave glowing reports to CFS comparing it to SD
    had no idea it had reniced X to -19 behind their back and that they were
    comparing it to SD running X at nice 0. I think had they been comparing CFS
    with X nice -19 to SD running nice -10 in this interactivity soft and squishy
    comparison land their thoughts might have been different. I missed it in the
    announcement and had to go looking in the code since Willy just kinda tripped
    over it unwittingly as well.

    > Note that Willy reniced X back to 0 so it had no relevance on
    > his test.

    Oh yes I did notice that, but since the array swap is the remaining longest
    deadline in SD which would cause noticeable jerks, renicing X on SD by
    default would make the experience very different since reniced tasks do much
    better over array swaps compared to non niced tasks. I really should go and
    make the whole thing one circular list and blow away the array swap (if I can
    figure out how to do it).

    > Also note that i pointed this change out in the -v4 CFS
    > announcement:
    > || Changes since -v3:
    > ||
    > || - usability fix: automatic renicing of kernel threads such as
    > || keventd, OOM tasks and tasks doing privileged hardware access
    > || (such as Xorg).

    Reading the changelog in the gloss-over fashion that I unfortunately did, even
    I missed it.

    > i've attached it below in a standalone form, feel free to put it into
    > SD! :)

    Hmm well I have tried my very best to do all the changes without
    changing "policy" as much as possible since that trips over so many emotive
    issues that noone can agree on, and I don't have a strong opinion on this as
    I thought it would be better for it to be a config option for X in userspace
    instead. Either way it needs to be turned on/off by admin and doing it by
    default in the kernel is... not universally accepted as good. What else
    accesses ioports that can get privileged nice levels? Does this make it
    relatively exploitable just by poking an ioport?

    > Ingo
    > ---
    > arch/i386/kernel/ioport.c | 13 ++++++++++---
    > arch/x86_64/kernel/ioport.c | 8 ++++++--
    > drivers/block/loop.c | 5 ++++-
    > include/linux/sched.h | 7 +++++++
    > kernel/sched.c | 40

    Thanks for the patch. I'll consider it. Since end users are testing this in
    fuzzy interactivity land I may simply be forced to do this just for
    comparisons to be meaningful between CFS and SD otherwise they're not really
    comparing them on a level playing field. I had almost given up SD for dead
    meat with all the momentum CFS had gained... until recently.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-22 02:03    [W:0.034 / U:4.304 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site