[lkml]   [2007]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: is RSDL an "unfair" scheduler too?
    On 3/19/07, David Schwartz <> wrote:
    > > I didn't suggest adding any unfairness! I suggested being fair by
    > > user/job/process instead of being fair by thread (which is actually
    > > unfair as it favors multi threaded processes over single threaded
    > > processes).
    > Wouldn't that be unfair because it favors multi-user approaches over
    > single-user approaches with the same number of processes?

    Not necessarily. Use GID rotations too.
    And if you can't assign these properly, it's your own/your distro's fault.

    > Consider two otherwise equivalent web server designs. They both use a helper
    > process owned by the user who owns the file the web server is sending. One
    > does a lot of work in the helper process, the other does very little. A
    > "fair by user" scheduler would give the approach that puts more work in the
    > helper process more CPU than the one that puts little work in the helper
    > process.

    Indeed, it's a drawback. Though a configurable one.

    > Being fair by user builds lots of assumptions into the scheduler. When
    > they're not true, the scheduler becomes sub-optimal. For example, consider a
    > web server that runs two very important tools, 'foo' and 'bar'. Rather than
    > running them as root, they run as users 'foo' and 'bar' for security. "Fair
    > to user" would mean that just because most other people are using 'foo', I
    > get less CPU when I try to use 'foo', because the OS doesn't know the "real
    > user", just the fake user who owns the process -- a security decision that
    > has no relationship to fairness. This would be handled perfectly by a "fair
    > to process" approach.

    Then, use a group quota. But checking that will be slower, and that
    overhead might kill other gains.

    > As for favoring multi-threaded processes over single-threaded processes,
    > sometimes that's what you want.

    Not on desktop.

    Typical multi-threaded workloads:
    - apache
    - some P2P clients
    - some audio servers/applications (small number of threads)

    Single-threaded is much more popular.

    > Consider two servers,
    ^ ^ ^

    Well, aren't we discussing desktops?
    Server admins can fine-tune the rights and CPU quotas per group.

    > one using thread per
    > job the other using process per job. Does it make sense to give the "process
    > per job" server as much CPU to do a single task as the "thread per job"
    > server gets for all the clients it's dealing with?

    Not necessarily. You see, the processes themselves are schedulable,
    the threads aren't.

    > It's really more important that the scheduler be tunable and predictable.

    This kind of scheduler, yes. Except it's much more tunable than a
    simple fair or unfair scheduler, and much more suited to real-time

    > That way, we can tell it what we want and get it. But the scheduler cannot
    > read our minds.

    That's why the per-user or per-group part would have to be optional.
    It just doesn't make much sense on single-user desktops.
    Then, RSDL design or even RSDL+bonus could be used.

    The bonus part would have to be really simple, e.g. priority
    inheritance for pipes, startup priority boost for nice 0 tasks.
    (warning - fork bombs. :P )
    No sleep estimator. Maybe these would suffice?

    The interactive bonus would be disabled by default, same as
    per-user/per-group scheduling.

    Some syscalls would have to be added, maybe using LSM framework?
    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-03-19 14:29    [W:0.026 / U:0.960 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site