Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group