Re: [BUGS] BUG #2401: spinlocks not available on amd64
On Apr 19, 2006, at 11:17 PM, Bruce Momjian wrote: Theo Schlossnagle wrote: The following bug has been logged online: Bug reference: 2401 Logged by: Theo Schlossnagle Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Solaris 10 Description:spinlocks not available on amd64 Details: Compiling 8.1.3 on solaris 10 x86 with Sun Studio 11 for amd64 target architecture leads us to an error resulting from no available "tas" assembly. The tas.s file doesn't look like valid assembly for the shipped Sun assembler. Yes. We will have a fix for it in 8.2, but it was too risky for 8.1.X. You can try a snapshot tarball from our FTP server and see if that works. I reviewed the code there. I think it can be better. The issue is that s_lock chooses to implement the lock in an unsigned char which isn't optimal on sparc or x86. An over arching issue is that the tas instruction is a less functional cas function, so it seems that the tas should be cas and the spinlocks should be implemented that way. By using cas, you can can actually know the locker by cas'ing the lock to the process id instead of 1 -- we use that trick to see who is holding the spinlock between threads (we obviously use thread ids in that case). So... I changed the s_lock.h to merge the sparc and x86 sections thusly: - #if defined(__sun) && (defined(__i386) || defined(__amd64) || defined (__sparc) | | defined(__sparc__)) /* * Solaris/386 (we only get here for non-gcc case) */ #define HAS_TEST_AND_SET typedef unsigned int slock_t; extern volatile slock_t pg_atomic_cas(volatile slock_t *lock, slock_t with, slock_t cmp); #define TAS(a) (pg_atomic_cas((a), 1, 0) != 0) #endif - And then replaced solaris_sparc.s and solaris_i386.s (BTW there is no reason to have these files seprately as you can #ifdef them correctly in the assembly -- I didn't do that as I didn't want to disturb the make system). solaris_sparc.s - / = / tas.s -- compare and swap for solaris_sparc / = #if defined(__sparcv9) || defined(__sparc) .section".text" .align 8 .skip 24 .align 4 .global pg_atomic_cas pg_atomic_cas: cas [%o0],%o2,%o1 mov %o1,%o0 retl nop .type pg_atomic_cas,2 .size pg_atomic_cas,(.-pg_atomic_cas) #endif - solaris_i386.s - / = / tas.s -- compare and swap for solaris_i386 / = .file "tas.s" #if defined(__amd64) .code64 #endif .globl pg_atomic_cas .type pg_atomic_cas, @function .section .text, "ax" .align 16 pg_atomic_cas: #if defined(__amd64) movl %edx,%eax lock cmpxchgl %esi,(%rdi) #else movl4(%esp), %edx movl8(%esp), %ecx movl12(%esp), %eax lock cmpxchgl %ecx, (%edx) #endif ret .size pg_atomic_cas, . - pg_atomic_cas - // Theo Schlossnagle // CTO -- http://www.omniti.com/~jesus/ // OmniTI Computer Consulting, Inc. -- http://www.omniti.com/ // Ecelerity: Run with it. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2401: spinlocks not available on amd64
Robert, Is there someone on the Solaris build team who should be seeing this thread? Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2401: spinlocks not available on amd64
Tom Lane wrote: Bruce Momjian writes: OK, this is a great help. If you think it should be just one file we can do that, but since the are separate instructions sets, separate files I think still makes sense. There is no reason for the i386 or AMD64 code to be different from what's already tested on Linux --- the hardware's the same and the OS surely doesn't make a difference at this level. On linux you use gcc, which allows for inline assembly. So, the code is already very different. Solaris cc doesn't support inline assemly unless you use .il files (which is a management and build nightmare). GCC's sparc backend is pretty awful, so it makes sense to embrace Sun Studio 11 (it's free after all) to make Postgres run reasonably well on sparc. While we're at it, it makes good sense to unify the methodology of builds on Solaris (regardless of the architecture). "as" on Solaris is shipped as a part of the core system -- so it is available without Sun Studio and will interoperate with other gcc compiled objects for a painless linkage. Yes there is a reason to use different code on Opteron than on i386. It requires less insutruction to do cas operations on opteron than on 80386. It is a tiny amount of code and well test on Solaris. It's in solaris_XXX.s files, so clearly it is different already. i386 and amd64 have different instruction sets and different registers and thus performing 32bit ops inside a 64bit program on opteron requires less register "setup" -- you can save 2 or 3 instructions. Regardless, the code I provided has far fewer instructions for the spinlocks than the code that was there. Does Solaris' assembler really support C-style "#if defined()" constructs in .s files? That seems moderately unlikely. Yes. That's the code I used to compile my stuff. Solaris's assembler certainly allows CPP (it's the -P flag). It allows easily building dual architecture builds from the same file with simply different flags to compile instead of different build object sources. With the provided files you can compile sparcv8plus (32bit) sparcv9 (64bit) i386 (32bit) and amd64 (64bit). (intel) as -K PIC -P tas.s (amd64) as -K PIC -P -xarch=amd64 tas.s (sparcv8plus) as -K PIC -P -xarch=sparcv8plus tas.s (sparcv9) as -K PIC -P -xarch=sparcv9 tas.s Separating the files out is as simple as making four different files (three in this case as sparcv8plus and sparcv9 use the same asm for 32bit cas). I would still put them in seperate files as you may want to add 64bit atomics at some point in the future and then the sparcv8plus and sparcv9 stuff will differ. Since the code is so small in the first place, it makes sense to me to put them in one file -- but that is clearly just a personal preference. My changes are just offered back. I made them because I wanted to get Pg to compile on my box, but while I was at it, I believe I reduced the complexity of code and offered (with pg_atomic_cas) an opportunity to ascertain _who_ holds the lock when you have spinlock contention. (as you could potentially cas the lock to the pg procpid instead of 1 at no additional cost). Best regards, Theo -- // Theo Schlossnagle // Principal Engineer -- http://www.omniti.com/~jesus/ // Ecelerity: Run with it. -- http://www.omniti.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] [Win32] Problem with rename()
This is probably somewhat superfluous, but we had another one these incidents last night whose details confirm your explanation here. [2006-04-21 00:22:19.500 ] 2452 LOG: could not rename file "pg_xlog/0001011A004C" to "pg_xlog/0001011A0071", continuing to try the autovacuums (which wouldn't actually have been vacuuming anything since update traffic would have stopped by then) continued until: [2006-04-21 01:57:35.968 ] 4048 LOG: autovacuum: processing database "bigbird" and the Web site first started noticing timeouts at 01:31:42,827. Overnight traffic is so light that 70 minutes to work through 32K / 2 transactions is probably about right. Pete >>> Tom Lane <[EMAIL PROTECTED]> 04/18/06 9:01 pm >>> [ thinks for awhile longer ... ] No, I take that back. Once you'd exhausted the current pg_clog page (32K transactions), even read-only transactions would be blocked by the need to create a new pg_clog page (which is a WAL-logged action). A read-only transaction never actually makes a WAL entry, but it does still consume an XID and hence a slot on the current pg_clog page. So I just hadn't tried enough transactions. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2401: spinlocks not available on amd64
I'm copying Jim Gates who has started looking into this issue. He's out this week. -Robert Joshua Berkus wrote: Robert, Is there someone on the Solaris build team who should be seeing this thread? Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
