Re: [PATCH] Staircase Scheduler v6.3 for 2.6.7-rc2

[Con Kolivas]

Quoting Phy Prabab <phyprabab@xxxxxxxxx>:

> 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
> 
Hi.

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
yield().

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
1.

Con

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/