netdev - Re: [tbench regression fixes]: digging out smelly deadmen.

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: <1223791374.7521.59.camel@marge.simson.net>
Date:	Sun, 12 Oct 2008 08:02:54 +0200
From:	Mike Galbraith <efault@....de>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Evgeniy Polyakov <s0mbre@...rvice.net.ru>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	David Miller <davem@...emloft.net>
Subject: Re: [tbench regression fixes]: digging out smelly deadmen.

On Sat, 2008-10-11 at 20:13 +0200, Mike Galbraith wrote:
> On Sat, 2008-10-11 at 16:39 +0200, Peter Zijlstra wrote:
> 
> > That said, we can probably still avoid the division for the top level
> > stuff, because the sum of the top level weights is still invariant
> > between all tasks.
> 
> Less math would be nice of course...
> 
> > I'll have a stab at doing so... I initially didn't do this because my
> > first try gave some real ugly code, but we'll see - these numbers are a
> > very convincing reason to try again.
> 
> ...but the numbers I get on Q6600 don't pin the tail on the math donkey.

Since I showed the rest of my numbers, I may as well show freshly
generated oltp numbers too.  Chart attached.  2.6.27.rev is 2.6.27 with
weight/asym changes reverted.

Data:

read/write requests/sec per client count
                            1       2       4       8      16      32      64     128     256  
2.6.26.6.mysql		 7978	19856	37238	36652	34399	33054	31608	27983	23411
2.6.27.mysql		 9618	18329	37128	36504	33590	31846	30719	27685	21299
2.6.27.rev.mysql	10944	19544	37349	36582	33793	31744	29161	25719	21026
2.6.28.git.mysql	 9518	18031	30418	33571	33330	32797	31353	29139	25793
									
2.6.26.6.pgsql		14165	27516	53883	53679	51960	49694	44377	35361	32879
2.6.27.pgsql		14146	27519	53797	53739	52850	47633	39976	30552	28741
2.6.27.rev.pgsql	14168	27561	53973	54043	53150	47900	39906	31987	28034
2.6.28.git.pgsql	14404	28318	55124	55010	55002	54890	53745	53519	52215

Less cycles used on math is still better of course, but my box seems to
care a lot more about preemption timing than math, regardless of load.

	-Mike

Aside:  Don't pay too much attention to mysql client < cores (4)
numbers, these jitter considerably.

Aside2:  Inquiring minds may wonder about pgsql numbers - preempting
holder of nasty userland spinlock hurts like heck.  It's triggered by
short term fairness, too much, and you pay.  Easy to cure, but you pay
for the cure too.  Moral of story is if you're running heavily loaded
server, turn preemption knobs, you'll lose peak, but scale better.

Download attachment "zzz.pdf" of type "application/pdf" (29786 bytes)