Re: Spinlocks, yet again: analysis and proposed patches - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: Spinlocks, yet again: analysis and proposed patches
Date
Msg-id Pine.LNX.4.58.0509140956450.2780@linuxworld.com.au
Whole thread Raw
In response to Re: Spinlocks, yet again: analysis and proposed patches  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Spinlocks, yet again: analysis and proposed patches
List pgsql-hackers
On Tue, 13 Sep 2005, Stephen Frost wrote:

> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > I'm starting to think that we might have to succumb to having a compile
> > option "optimize for multiprocessor" or "optimize for single processor".
> > It's pretty hard to see how we'd alter a data structure decision like
> > this on the fly.
>
> I'd really hate to see this happen.  In this case I don't think the
> change you're proposing would have much of an impact on a uniprocessor
> machine.  Having seperate compile-time options for uniprocessor and
> multiprocessor would open the gates for potentially other changes which
> *would* have a more serious impact on one or the other when compiled for
> the opposite.  I think this would be a serious problem for binary
> distributions and correspondingly their users.

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.

Gavin


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Spinlocks, yet again: analysis and proposed patches
Next
From: Stephen Frost
Date:
Subject: Re: Spinlocks, yet again: analysis and proposed patches