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]

Date:	Fri, 23 May 2008 12:10:00 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Mike Galbraith <efault@....de>
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+


* 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?

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

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

	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/