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

> 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@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: 2005-03-22 14:03    [from the cache]
©2003-2011 Jasper Spaans