Re: Spinlocks, yet again: analysis and proposed patches

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Marko Kreen <marko(at)l-t(dot)ee>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Spinlocks, yet again: analysis and proposed patches
Date: 2005-09-14 00:14:47
Message-ID: 20050914001447.GO6026@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Gavin Sherry (swm(at)linuxworld(dot)com(dot)au) wrote:
> It does make it painful for distribution/package maintainers but I think
> the potential benefits for single/multi-CPU architectures are high. It
> means that our lock intrinsic on uniprocessors can just be a lock/delay
> loop without any spinning -- which is a complete waste of time if you only
> have one CPU.
>
> Doing this at runtime involvevs some pretty significant uglification of
> low level code I think.

I suspect distributors would go for the multi-cpu setup (especially if
a uniprocessor build is *broken* for multiprocessor) and then in a
lot of cases you end up not actually getting any benefit. I'm afraid
you'd also end up having to tell alot of people who complain to
recompile, who will then complain back to their distributors, etc.

I suppose another option would be to provide seperate packages... Could
this be done as a shared library so it's more 'plug-and-play' to switch
between the two? I dunno, just trying to think about how to deal with
this without making it suck terribly bad for me (as a Debian user and
maintainer).

Certainly makes me wish there was a way to do it which made the kernel
handle the uniprocessor/multiprocessor question and did locking as
appropriate for those. Ah, well.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pryscila B Guttoski 2005-09-14 00:40:45 Re: About method of PostgreSQL's Optimizer
Previous Message Gavin Sherry 2005-09-14 00:05:59 Re: Spinlocks, yet again: analysis and proposed patches