lkml.org 
[lkml]   [2007]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2
    Date

    > * Mike Galbraith <efault@gmx.de> wrote:
    >
    > > [...] The situation as we speak is that you can run cpu intensive
    > > tasks while watching eye-candy. With RSDL, you can't, you feel the
    > > non-interactive load instantly. [...]
    >
    > i have to agree with Mike that this is a material regression that cannot
    > be talked around.

    I don't know what else you can do when the argument is that behavior that is
    wrong is what you actually want. The regression is not that the scheduler
    doesn't do what it was asked to do or even that it isn't more faithful to
    what it was told to do than the scheduler it replaces. The regression is
    that the scheduler didn't do what Mike wanted it to do, even though he
    didn't ask it to do that.

    I would argue this is progression, not regression. The new scheduler is
    fairer than the old one and fairness is good even though it sometimes hurts
    some tasks.

    > Con, we want RSDL to /improve/ interactivity.

    Not when the interactivity was the result of unfairness.

    > Having new scheduler
    > interactivity logic that behaves /worse/ in the presence of CPU hogs,
    > which CPU hogs are even reniced to +5, than the current interactivity
    > code, is i think a non-starter. Could you try to fix this, please?

    If you did this, it would mean that all the space between the signficant
    level of unfairness you want in this case and pure fairness would have to
    fit in five nice levels. That just seems like poor granularity.

    > Good
    > interactivity in the presence of CPU hogs (be them default nice level or
    > nice +5) is _the_ most important scheduler interactivity metric.
    > Anything else is really secondary.

    Good interactivity for tasks that aren't themselves CPU hogs. A task should
    get low latency if and only if it's yielding the CPU voluntarily most of the
    time. If it's not, it can only get better interactivity at the cost of
    fairness, and you have to *ask* for that. (Common sense says you can't give
    a task *more* CPU because it yields the CPU a lot. And how else do you
    determine interactivity other than nice level?)

    This scheduler will not give you greater interactivity at the cost of
    fairness unless you really ask for it. I think that's a good thing, though I
    do agree it might take some getting used to.

    I'm not saying it is impossible to make RSDL better at handling this
    particular job. I'm saying the "regression" may be the scheduler doing what
    it was asked to do more faithfully than the current scheduler and the right
    fix (at least in the longer term) is to ask for what you really want.

    DS


    -
    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: 2007-03-13 16:19    [W:6.486 / U:0.240 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site