lkml.org 
[lkml]   [2007]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
    On Wed, Apr 18, 2007 at 01:55:34AM -0500, Matt Mackall wrote:
    > On Wed, Apr 18, 2007 at 08:37:11AM +0200, Nick Piggin wrote:
    > > I don't know how that supports your argument for unfairness,
    >
    > I never had such an argument. I like fairness.
    >
    > My argument is that -you- don't have an argument for making fairness a
    > -requirement-.

    It seems easy enough that there is no point accepting unfair
    behaviour like the old scheduler if we're going to go to all
    this trouble to replace it. The old scheduler seems to have
    bounded unfairness and bounded starvation, so let the good times
    roll.


    > > processes are special only because that's how we've always done
    > > scheduling. I'm not precluding other groupings for fairness, though.
    >
    > If you make one form of fairness a -requirement- for all acceptable
    > algorithms, your -are- precluding most other forms of fairness.
    >
    > If you refuse to define what "fairness" means when specifying your
    > requirement, what's the point of requiring it?

    I don't refuse. I'm talking about per-process CPU time fairness.
    My paragraph above was pointing out that subsequent work to
    add other classes of fairness are not excluded as configurable
    features, but this basic type of fairness should be included.


    > > What do you mean optimal? If your criteria is fairness, then of course
    > > it is optimal. If your criteria is throughput, then it probably isn't.
    >
    > I don't know what optimal behavior is. And neither do you. It may or
    > may not be fair. It very likely includes small deviations from fair.

    You misunderstand me. There is no single "optimal" when you're talking
    about fairness (or most other scheduler things). So pondering whether
    fairness is optimal or not doesn't really make sense.

    I'm saying it should be a basic axiom, not that it is quantitively
    better. It isn't a refutable argument. I state it because that it is
    what users and programs expect.

    You can reject that, and fine. I guess if a scheduler comes along that
    does exactly the right thing for everyone, then it is better than any
    fair scheduler. So OK, while we're talking theoretical, I won't dismiss
    an unfair scheduler out of hand.


    > > > [2] It's trivial to construct two or more perfectly reasonable and
    > > > desirable definitions of fairness that are mutually incompatible.
    > >
    > > Probably not if you use common sense, and in the context of a replacement
    > > for the 2.6 scheduler.
    >
    > Ok, trivial example. You cannot allocate equal CPU time to
    > processes/tasks and simultaneously allocate equal time to thread
    > groups. Is it common sense that a heavily-threaded app should be able
    > to get hugely more CPU than a well-written app? No. I don't want Joe's
    > stupid Java app to make my compile crawl.
    >
    > On the other hand, if my heavily threaded app is, say, a voicemail
    > server serving 30 customers, I probably want it to get 30x the CPU of
    > my gzip job.

    So that might be a nice addition, but the base funcionality is threads
    simply because that's what we've always done. Just common sense.

    -
    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-04-18 09:27    [W:5.551 / U:0.152 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site