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

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 (view raw or flat)
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

pgsql-performance by date

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

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