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]
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)

Powered by blists - more mailing lists