Re: [HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Tom Lane
Martijn van Oosterhout writes: > On Tue, Oct 11, 2005 at 02:28:02PM -0400, Tom Lane wrote: >> One thought that comes to mind is that these decisions are probably >> comparable to those made by gcc conditional on -march flags. Do we >> get access to the -march setting by means of predefined symbol

Re: [HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Peter Eisentraut
Simon Riggs wrote: > Tom is suggesting having different behaviour for x86 and x86_64. The > x86 will still run on x86_64 architecture would it not? So we'll have > two binaries for each OS, yes? A quick glance around tells me that most free operating systems are treating x86 and x86_64 as separat

Re: [HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Martijn van Oosterhout
On Tue, Oct 11, 2005 at 02:28:02PM -0400, Tom Lane wrote: > One thought that comes to mind is that these decisions are probably > comparable to those made by gcc conditional on -march flags. Do we > get access to the -march setting by means of predefined symbols? > If so we could compile different

Re: [HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > On Tue, 2005-10-11 at 18:45 +0200, Peter Eisentraut wrote: >> A number of packages in the video area (and perhaps others) do compile >> "sub-architecture" specific variants. This could be done for >> PostgreSQL, but you'd probably need to show some prett

Re: [HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Dann Corbit
postgresql.org; Tom Lane > Subject: Re: [HACKERS] Spinlocks and CPU Architectures > > On Tue, 2005-10-11 at 18:45 +0200, Peter Eisentraut wrote: > > Tom Lane wrote: > > > This seems pretty unworkable from a packaging standpoint. Even if > > > you teach autoconf h

Re: [HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Simon Riggs
On Tue, 2005-10-11 at 18:45 +0200, Peter Eisentraut wrote: > Tom Lane wrote: > > This seems pretty unworkable from a packaging standpoint. Even if > > you teach autoconf how to tell which model it's running on, there's > > no guarantee that the resulting executables will be used on that same > > m

Re: [HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Peter Eisentraut
Tom Lane wrote: > This seems pretty unworkable from a packaging standpoint. Even if > you teach autoconf how to tell which model it's running on, there's > no guarantee that the resulting executables will be used on that same > machine. A number of packages in the video area (and perhaps others)

Re: [HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Martijn van Oosterhout
On Tue, Oct 11, 2005 at 11:12:46AM -0400, Tom Lane wrote: > This seems pretty unworkable from a packaging standpoint. Even if you > teach autoconf how to tell which model it's running on, there's no > guarantee that the resulting executables will be used on that same > machine. We would have to m

Re: [HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > The long history of spinlock issues has recently been attacked > significantly by Tom, but I wanted to get a status on this issue before > we release 8.1 I'd still like to do something more with that before we release, but exactly what is TBD. > The concl

Re: [HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Emil Briggs
> > Do other people reach the same conclusions? > > Can we make a list of those architectures for which 8.1 is known to > perform reasonably well, with reasonable SMP scalability? I suggest that > we record this list somewhere in the release notes, but with a comment > to say we run on other archit

[HACKERS] Spinlocks and CPU Architectures

2005-10-11 Thread Simon Riggs
The long history of spinlock issues has recently been attacked significantly by Tom, but I wanted to get a status on this issue before we release 8.1 My understanding of the problems of spinlocking has been greatly enhanced by two recent articles: Linux Journal, discussing linux SMP portability i