Re: PostgreSQL pgbench performance regression in 2.6.23+
From: Mike Galbraith
Date: Fri May 23 2008 - 06:15:30 EST
On Fri, 2008-05-23 at 12:10 +0200, Ingo Molnar wrote:
> * Mike Galbraith <efault@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/