> 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: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver
pgpgEbzHujiUn.pgp
Description: PGP signature
