linux-kernel - 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] [thread-next>] [day] [month] [year] [list]

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

* Michael Gerdau <mgd@...hnosis.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
-
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/