[lkml]   [2004]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Staircase Scheduler v6.3 for 2.6.7-rc2
    Quoting Phy Prabab <>:

    > OOOPPPSSSS....
    > I need to make a correction on my previous data. I
    > had inadvertantly turned off interactivity and also
    > increased the compute time to 100. I confirmed that
    > just setting interactivity off, does not solve my
    > problem:
    > 2.6.7-rc3-s63 (0 @ /proc/sys/kernel/interactive):
    > A: 37.30user 40.56system 1:42.01elapsed 76%CPU
    > B: 37.29user 40.35system 1:23.87elapsed 92%CPU
    > C: 37.30user 40.56system 1:36.01elapsed 81%CPU
    > 2.6.7-rc3-s63 (0 @ /proc/sys/kernel/interactive & 1
    > /proc/sys/kernel/compute):
    > A: 37.28user 40.36system 1:25.60elapsed 90%CPU
    > B: 37.22user 40.35system 1:22.17elapsed 94%CPU
    > C: 37.27user 40.35system 1:24.71elapsed 91%CPU
    > The question here, noticing that user and kernel time
    > are the same, where is the dead time coming from and
    > why is it sooooo much more deterministic with compute
    > time at 100 vs 10? Maybe I am misinterpreting the
    > data, but this suggests to me that something is going
    > awry (ping-pong, no settle, ???) within the kernl?
    > Also please note the degredation between
    > 2.6.7-rc2-bk8-s63:
    > A: 35.57user 38.18system 1:20.28elapsed 91%CPU
    > B: 35.54user 38.40system 1:19.48elapsed 93%CPU
    > C: 35.48user 38.28system 1:20.94elapsed 91%CPU
    > Interesting how much more time is spent in both user
    > and kernel space between the two kernels. Also note
    > that 2.4.x exhibits even greater delta:
    > A: 28.32user 29.51system 1:01.17elapsed 93%CPU
    > B: 28.54user 29.40system 1:01.48elapsed 92%CPU
    > B: 28.23user 28.80system 1:00.21elapsed 94%CPU
    > Could anyone suggest a way to understand why the
    > difference between the 2.6 kernels and the 2.4
    > kernels?
    > Thank you for your time.
    > Phy

    How repeatable are the numbers normally? Some idea of what it is you're
    benchmarking may also help in understanding the problem; locking may be an
    issue with what you're benchmarking and out-of-order scheduling is not as
    forgiving of poor locking. Extending the RR_INTERVAL and turning off
    interactivity makes it more in-order and more forgiving of poor locking or

    Compute==1 setting inactivates interactivity anyway, but that's not really
    relevant to your figures since you had set interactive 0 when you set compute


    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:03    [W:0.042 / U:0.044 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site