Re: futex results with dbt-3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: josh(at)agliodbs(dot)com
Cc: pgsql-performance(at)postgresql(dot)org, Manfred Spraul <manfred(at)colorfullife(dot)com>, neilc(at)samurai(dot)com, markw(at)osdl(dot)org
Subject: Re: futex results with dbt-3
Date: 2004-10-19 22:39:48
Message-ID: 27697.1098225588@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> The bigger problem here is that the SMP locking bottlenecks we are
>> currently seeing are *hardware* issues (AFAICT anyway).

> Well, initial results from Gavin/Neil's patch seem to indicate that, while
> futexes do not cure the CSStorm bug, they do lessen its effects in terms of
> real performance loss.

It would be reasonable to expect that futexes would have a somewhat more
efficient code path in the case where you have to block (mainly because
SysV semaphores have such a heavyweight API, much more complex than we
really need). However, the code path that is killing us is the one
where you *don't* actually need to block. If we had a proper fix for
the problem then the context swap storm itself would go away, and
whatever advantage you might be able to measure now for futexes likewise
would go away.

In other words, I'm not real excited about a wholesale replacement of
code in order to speed up a code path that I don't want to be taking
in the first place; especially not if that replacement puts a fence
between me and working on the code path that I do care about.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Russell Smith 2004-10-19 23:18:57 Re: Select with qualified join condition / Batch inserts
Previous Message Josh Close 2004-10-19 22:31:59 how much mem to give postgres?