Re: [REPORT] cfs-v6-rc2 vs sd-0.46 vs 2.6.21-rc7

[Ingo Molnar <mingo@elte.hu>]

* Michael Gerdau <mgd@technosis.de> wrote:

> In general sd tends to finish all three such jobs at roughly the same 
> time while cfs clearly "favors" the LTMM-type jobs (which admittedly 
> involve the least computations). I don't really know why that is so.

for the reason of this, look at the raw user runtimes the 3 jobs have:

  5498.128  secs            # LTMM
  7559.777  secs
  7600.179  secs

the "perfect scheduler" would run each of the jobs at 33.33% of capacity 
for ~5500 CPU-seconds, and would then run the remaining two jobs at 
50.0% capacity for about ~2075 CPU-seconds.

Why? Because the scheduler how no idea how much each job takes! So a 
fair scheduler would run: 3 jobs at 33.33% capacity for as long as the 
shortest job ends, then the remaining 2 jobs at 50% capacity for as the 
shorter one of the remaining 2 finishes, and the remaining one at 100%.

in your case that means that the best scheduling would be roughly the 
following ideal timeline:

   5500*3 / 2 ==  8250 seconds for the LTMM to finish
   2075*2 / 2 == +2075 more seconds for the other two jobs to finish.

the various runs showed the following wallclock-time timeline for the 
LTMM phase:

   CFS #1:  real    142m56.806s
   CFS #2:  real    125m58.235s
   SD:      real    140m16.127s
   vanilla: real    133m50.274s

the "ideal" is ~137 minutes (8250 seconds) for the LTMM phase. The 
closest was indeed SD, but vanilla and cfs #1 wasnt too far away from it 
either. [ and the variance between CFS #1 and #2 seems to suggest that 
the noise of this particular metric is significant. The average does 
come in at 134.5, which is quite close to the ideal number. ]

	Ingo