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

[Michael Gerdau <mgd@technosis.de>]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

> Very interesting indeed but fairly complicated as well.

Sorry for that -- I've taken these figures from the 3MB logfile
that each job creates and "reading" them on a regular basis tend
to forget that probably everyody else does not find them as
obvious as I do. Also I'm don't really have lots of experience
with how a scheduler is properly tested.

For any upcoming tests I will restrict the numbers to wallclock
and what time provides which probably is better suited anyway.

> > as a summary: i think your numbers demonstrate it nicely that the
> > shorter 'timeslice length' that both CFS and SD utilizes does not have a
> > measurable negative impact on your workload. To measure the total impact
> > of 'timeslicing' you might want to try the exact same workload with a
> > much higher 'timeslice length' of say 400 msecs, via:
> >
> >     echo 400000000 > /proc/sys/kernel/sched_granularity_ns  # on CFS
> >     echo 400 > /proc/sys/kernel/rr_interval                 # on SD
> 
> I thought that the effective "timeslice" on CFS was double the 
> sched_granularity_ns so wouldn't this make the effective timeslice double 
> that of what you're setting SD to? Anyway the difference between 400 and 
> 800ms timeslices is unlikely to be significant so I don't mind.

I'm happy to do that, hopefully over the weekend.

Best,
Michael
-- 
 Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar
 Sitz Hamburg; HRB 89145 Amtsgericht Hamburg
 Vote against SPAM - see http://www.politik-digital.de/spam/
 Michael Gerdau       email: mgd@technosis.de
 GPG-keys available on request or at public keyserver

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]