Re: futex results with dbt-3 - Mailing list pgsql-performance

From Dave Cramer
Subject Re: futex results with dbt-3
Date
Msg-id 41770285.5090604@fastcrypt.com
Whole thread Raw
In response to Re: futex results with dbt-3  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Forgive my naivete, but do futex's implement some priority algorithm for
which process gets control. One of the problems as I understand it is
that linux does (did ) not implement a priority algorithm, so it is
possible for the context which just gave up control to be the next
context woken up, which of course is a complete waste of time.

--dc--

Tom Lane wrote:

>Manfred Spraul <manfred@colorfullife.com> writes:
>
>
>>Tom Lane wrote:
>>
>>
>>>The bigger problem here is that the SMP locking bottlenecks we are
>>>currently seeing are *hardware* issues (AFAICT anyway).  The only way
>>>that futexes can offer a performance win is if they have a smarter way
>>>of executing the basic atomic-test-and-set sequence than we do;
>>>
>>>
>>>
>>lwlocks operations are not a basic atomic-test-and-set sequence. They
>>are spinlock, several nonatomic operations, spin_unlock.
>>
>>
>
>Right, and it is the spinlock that is the problem.  See discussions a
>few months back: at least on Intel SMP machines, most of the problem
>seems to have to do with trading the spinlock's cache line back and
>forth between CPUs.  It's difficult to see how a futex is going to avoid
>that.
>
>            regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
>      subscribe-nomail command to majordomo@postgresql.org so that your
>      message can get through to the mailing list cleanly
>
>
>
>

--
Dave Cramer
www.postgresintl.com
519 939 0336
ICQ#14675561


pgsql-performance by date:

Previous
From: Mark Wong
Date:
Subject: Re: futex results with dbt-3
Next
From: jelle
Date:
Subject: iostat question