[lkml]   [2004]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] O(1) Entitlement Based Scheduler
    Andi Kleen wrote:
    > Peter Williams <> writes:
    > One comment on the patches: could you remove the zillions of numerical Kconfig
    > options and just make them sysctls? I don't think it makes any sense
    > to require a reboot to change any of that. And the user is unlikely
    > to have much idea yet on what he wants on them while configuring.

    The default initial values should be fine and the default configuration
    allows the scheduling tuning parameters (i.e. half life and time slice
    ) to be changed on a running system via the /proc file system.
    These are mainly there so that different settings can be used with
    various benchmarks to determine what are the best settings for various
    types of loads. If good default values that work well for a wide
    variety of load types can be found as a result of these experiments then
    these parameters may be made constants in the code. If not they
    probably should be made settable via system calls rather than via /proc
    as you suggest.

    In reality, batch type jobs tend to get better throughput with a longer
    half life but a shorter half life gives better interactive response. So
    servers and work stations should probably have different settings.

    > I really like the reduced scheduler complexity part of your patch BTW.
    > IMHO the 2.6 scheduler's complexity has gotten out of hand and it's great
    > that someone is going into the other direction with a simple basic design.

    Thanks, we felt much the same. With a heuristic approach there always
    seems to be one more case that needs to be handled specially popping up.

    > For more wide spread testing it would be useful if you could do
    > a more minimal less intrusive patch with less configuration
    > (e.g. only allow tuning via nice, not via other means). This would
    > be mainly to test your patch on more workloads without any hand tuning,
    > which is the most important use case.

    The "base" patch does this except that it also allows the setting of
    soft caps via /proc. But, as I said above, the main reason for the
    tuning parameters being exposed (in the full patch) at this time is to
    encourage testing with different values (of half life and time slice)
    and making them settable via /proc makes this possible without having to
    reboot the system.

    Except for (possibly) renicing the X server there should be no need to
    fiddle with settings for individual tasks.

    PS We are looking at some simple modifications to further improve
    interactive response (hopefully) without adding to complexity.
    Dr Peter Williams, Chief Scientist
    Aurema Pty Limited Tel:+61 2 9698 2322
    PO Box 305, Strawberry Hills NSW 2012, Australia Fax:+61 2 9699 9174
    79 Myrtle Street, Chippendale NSW 2008, Australia

    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: 2005-03-22 14:01    [W:0.025 / U:3.612 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site