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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 27 Apr 2007 07:59:07 +0200
From:	Michael Gerdau <mgd@...hnosis.de>
To:	Con Kolivas <kernel@...ivas.org>
Cc:	ck@....kolivas.org, Ingo Molnar <mingo@...e.hu>,
	Nick Piggin <npiggin@...e.de>,
	Bill Davidsen <davidsen@....com>,
	Juliusz Chroboczek <jch@....jussieu.fr>,
	Mike Galbraith <efault@....de>, linux-kernel@...r.kernel.org,
	William Lee Irwin III <wli@...omorphy.com>,
	Peter Williams <pwil3058@...pond.net.au>,
	Gene Heskett <gene.heskett@...il.com>,
	Willy Tarreau <w@....eu>, Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [ck] Re: [REPORT] cfs-v6-rc2 vs sd-0.46 vs 2.6.21-rc7

> 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@...hnosis.de
 GPG-keys available on request or at public keyserver

Content of type "application/pgp-signature" skipped