Re: PostgreSQL pgbench performance regression in 2.6.23+

[Mike Galbraith <efault@gmx.de>]

On Fri, 2008-05-23 at 12:10 +0200, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.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