Re: futex results with dbt-3

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

Mark Wong wrote:

>Pretty, simple. One to load the database, and 1 to query it. I'll
>attach them.
>
>
>
I've tested it on my dual-cpu computer:
- it works, both cpus run within the postmaster. It seems something your
gentoo setup is broken.
- the number of context switch is down slightly, but not significantly:
The glibc implementation is more or less identical to the implementation
right now in lwlock.c: a spinlock that protects a few variables that are
used to implement the actual mutex, several wait queues: one for
spinlock busy, one or two for the actual mutex code.

Around 25% of the context switches are from spinlock collisions, the
rest are from actual mutex collisions. It might be possible to get rid
of the spinlock collisions by writing a special, futex based semaphore
function that only supports exclusive access [like sem_wait/sem_post],
but I don't think that it's worth the effort: 75% of the context
switches would remain.
What's needed is a buffer manager that can do lookups without a global lock.

--
Manfred

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Matthew T. O'Connor 2004-10-22 21:13:18 Re: Performance Anomalies in 7.4.5
Previous Message Tom Lane 2004-10-22 20:45:51 Re: [PATCHES] ARC Memory Usage analysis