On Thu, 17 Apr 2008, Greg Smith wrote:
So in the case of this simple benchmark, I see an enormous performance
regression from the newest Linux kernel compared to a much older one. I need
to do some version bisection to nail it down for sure, but my guess is it's
the change to the Completely Fair Scheduler in 2.6.23 that's to blame.
That's a bit sad. From Documentation/sched-design-CFS.txt (2.6.23):
There is only one
central tunable (you have to switch on CONFIG_SCHED_DEBUG):
/proc/sys/kernel/sched_granularity_ns
which can be used to tune the scheduler from 'desktop' (low
latencies) to 'server' (good batching) workloads. It defaults to a
setting suitable for desktop workloads. SCHED_BATCH is handled by the
CFS scheduler module too.
So it'd be worth compiling a kernel with CONFIG_SCHED_DEBUG switched on
and try increasing that value, and see if that fixes the problem.
Alternatively, use sched_setscheduler to set SCHED_BATCH, which should
increase the timeslice (a Linux-only option).
Matthew
--
Psychotics are consistently inconsistent. The essence of sanity is to
be inconsistently inconsistent.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
