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:	Thu, 27 Sep 2007 10:35:06 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Antoine Martin <antoine@...afix.co.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Chuck Ebbert <cebbert@...hat.com>,
	Satyam Sharma <satyam.sharma@...il.com>,
	Linux Kernel Development <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: CFS: new java yield graphs


* Antoine Martin <antoine@...afix.co.uk> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> These are pure cpu scheduling tests, not doing any I/O this time. All 
> these tests are still "pathological" in the sense that they are only 
> meant to show differences between schedulers rather than try to 
> simulate real usage scenarios.

thanks for testing this!

> all the graphs are here:
> http://devloop.org.uk/lkml/

wow - really nice graphs!

> Legend:
> * 2.6.23-rc6-yield2: "yield2" patch is this one:
> http://lkml.org/lkml/2007/9/14/157
> * 2.6.23-rc6-yield2-highlatency is the same patch, but the kernel is
> built without preempt, with HZ100 and the scheduling granularity is
> doubled using sysctl.
> * 2.6.23-rc6-yield3 is CFS-v21 combo3 + the yield patch
> * 2.6.23-rc6-yield4 is this patch (queued for mainline? and in mm?):
> http://lkml.org/lkml/2007/9/19/409

wrt. yield4 did you set /proc/sys/kernel/sched_compat_yield to 1? 
(with sched_compat_yield at 0, which is the default, nothing 
changes)

which one would be your favorite kernel? To me yield4 looks pretty good.

> of interest I found:
> * rc6-mm1 is not always fair (see "ManyThreadsYieldOften" tests) - the
> only one to have almost half the threads already finished at the half
> way point when yielding often. Also slower for the "RandomSleep".
> * increasing latency makes a noticeable difference (see "ShortPause")
> it can be more fair, but it also makes it a lot more erratic (see
> "Yield" tests)
> * most changes are only noticeable with a large number for threads (look
> for 'ManyThreads' in the filename)

i'm wondering, how easy would it be for you to test the sched-devel.git 
tree? If you havent used git before then first install the 'git' 
package, then do:

  git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.git
  cd linux-2.6.git
  git-pull git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git

> PS: now testing -rc8, also added a test that consumes memory in each 
> thread. also now recording context switches and idle time.

ok.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ