linux-kernel - Re: [ck] Re: Scheduler benchmarks

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: <20070917141217.GA25956@elte.hu>
Date:	Mon, 17 Sep 2007 16:12:17 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jos Poortvliet <jospoortvliet@...il.com>
Cc:	Rob Hussey <robjhussey@...il.com>, ck@....kolivas.org,
	linux-kernel@...r.kernel.org
Subject: Re: [ck] Re: Scheduler benchmarks - a follow-up


* Jos Poortvliet <jospoortvliet@...il.com> wrote:

> On 9/17/07, Ingo Molnar <mingo@...e.hu> wrote:
> >
> > * Rob Hussey <robjhussey@...il.com> wrote:
> >
> > > http://www.healthcarelinen.com/misc/benchmarks/BOUND_hackbench_benchmark2.png
> >
> > heh - am i the only one impressed by the consistency of the blue line in
> > this graph? :-) [ and the green line looks a bit like a .. staircase? ]
> 
> Looks lovely, though as long as lower is better, that staircase does a 
> nice job ;-)

lower is better, but you have to take the thing below into account:

> > i've meanwhile tested hackbench 90 and the performance difference
> > between -ck and -cfs-devel seems to be mostly down to the more precise
> > (but slower) sched_clock() introduced in v2.6.23 and to the startup
> > penalty of freshly created tasks.
> >
> > Putting back the 2.6.22 version and tweaking the startup penalty gives
> > this:
> >
> >                             [hackbench 90, smaller is better]
> >
> >            sched-devel.git      sched-devel.git+lowres-sched-clock+dsp
> >            ---------------      --------------------------------------
> >                      5.555                  5.149
> >                      5.641                  5.149
> >                      5.572                  5.171
> >                      5.583                  5.155
> >                      5.532                  5.111
> >                      5.540                  5.138
> >                      5.617                  5.176
> >                      5.542                  5.119
> >                      5.587                  5.159
> >                      5.553                  5.177
> >            --------------------------------------
> >                 avg: 5.572             avg: 5.150 (-8.1%)
> 
> Hmmm. So cfs was 0.8% slower compared to ck in the test by Rob, it 
> became 8% faster so... it should be faster than CK - provided these 
> results are valid over different tests.

on my box the TSC overhead has hit CFS quite hard, i'm not sure that's 
true on Rob's box. So i'd expect them to be in roughly the same area.

> But this is all microbenchmarks, which won't have much effect in real 
> life, right? [...]

yeah, it's much less pronounced in real life - a context-switch rate 
above 10,000/sec is already excessive - while for example the lat_ctx 
test generates close to a million context switches a second.

> [...] Besides, will the lowres sched clock patch get in?

i dont think so - we want precise/accurate scheduling before 
performance. (otherwise tasks working off the timer tick could steal 
away cycles without being accounted for them fairly, and could starve 
out all other tasks.) Unless the difference was really huge in real life 
- but it isnt.

	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/