| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
| Cc: | neilc(at)samurai(dot)com, markw(at)osdl(dot)org, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: futex results with dbt-3 |
| Date: | 2004-10-19 21:52:13 |
| Message-ID: | 20151.1098222733@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> Has anyone tried to replace the whole lwlock implementation with
> pthread_rwlock? At least for Linux with recent glibcs, pthread_rwlock is
> implemented with futexes, i.e. we would get a fast lock handling without
> os specific hacks.
"At least for Linux" does not strike me as equivalent to "without
OS-specific hacks".
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;
and if so, we could read their code and adopt that method without having
to buy into any large reorganization of our code.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2004-10-19 21:59:48 | Re: futex results with dbt-3 |
| Previous Message | Matt Nuzum | 2004-10-19 19:55:04 | Re: Speeding up this function |