lkml.org 
[lkml]   [2012]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected

* Ingo Molnar <mingo@kernel.org> wrote:

> * Mike Galbraith <efault@gmx.de> wrote:
>
> > I think the pgbench problem is more about latency for the 1
> > in 1:N than spinlocks.
>
> So my understanding of the psql workload is that basically
> we've got a central psql proxy process that is distributing
> work to worker psql processes. If a freshly woken worker
> process ever preempts the central proxy process then it is
> preventing a lot of new work from getting distributed.

Also, I'd like to stress that despite the optimization dilemma,
the psql workload is *important*. More important than tbench -
because psql does some real SQL work and it also matches the
design of many real desktop and server workloads.

So if indeed the above is the main problem of psql it would be
nice to add a 'perf bench sched proxy' testcase that emulates it
- that would remove psql version dependencies and would ease the
difficulty of running the benchmarks.

We alread have 'perf bench sched pipe' and 'perf bench sched
messaging' - but neither shows the psql pattern currently.

I suspect a couple of udelay()s in the messaging benchmark would
do the trick? The wakeup work there already matches much of how
psql looks like.

Thanks,

Ingo


\
 
 \ /
  Last update: 2012-09-27 08:41    [W:0.139 / U:1.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site