linux-kernel - Re: PostgreSQL pgbench performance regression in 2.6.23+

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: <1211537717.5851.22.camel@marge.simson.net>
Date:	Fri, 23 May 2008 12:15:17 +0200
From:	Mike Galbraith <efault@....de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Greg Smith <gsmith@...gsmith.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Subject: Re: PostgreSQL pgbench performance regression in 2.6.23+


On Fri, 2008-05-23 at 12:10 +0200, Ingo Molnar wrote:
> * Mike Galbraith <efault@....de> wrote:
> 
> > My take on the numbers is that both kernels preempt too frequently for 
> > _this_ load.. but what to do, many many loads desperately need 
> > preemption to perform.
> > 
> >       2.6.22.18     2.6.22.18-batch          2.6.26.git    2.6.26.git.batch
> > 1   7487.115236         7643.563512         9999.400036         9915.823582
> > 2  17074.869889        15360.150210        14042.644140        14958.375329
> > 3  25073.139078        24802.446538        15621.206938        25047.032536
> > 4  24236.413612        26126.482482        16436.055117        25007.183313
> > 5  26367.198572        28298.293443        19926.550734        27853.081679
> > 6  24695.827843        30786.651975        22375.916107        28119.474302
> > 8  21020.949689        31973.674156        25825.292413        31070.664011
> > 10 22792.204610        31775.164023        26754.471274        31596.415197
> > 15 21202.173186        30388.559630        28711.761083        30963.050265
> > 20 21204.041830        29317.044783        28512.269685        30127.614550
> > 30 18519.965964        27252.739106        26682.613791        28185.244056
> > 40 17936.447579        25670.803773        24964.936746        26282.369366
> > 50 16247.605712        25089.154310        21078.604858        25356.750461
> 
> was 2.6.26.git.batch running the load with SCHED_BATCH, or did you do 
> other tweaks as well?

It was running SCHED_BATCH, features=0.

> if it's other tweaks as well then could you perhaps try to make 
> SCHED_BATCH batch more agressively?

That's what I was thinking, because it needed features=0 as well to
achieve O(1) batch performance.

> I.e. i think it's a perfectly fine answer to say "if your workload needs 
> batch scheduling, run it under SCHED_BATCH".

Yes, and this appears to be such a case.

	-Mike

--
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/