Porting PostgreSQL - TAS definitions on Solaris x86 with GCC

Author

TAS definitions on Solaris x86 with GCC

Michael Crozier

2005-09-27, 8:24 pm

Hello,

I'm again looking at tas/spinlock build problems while investigating unusually
high CPU usage during load testing. My issue was first mentioned here:

http://archives.postgresql.org/pgsq...09/msg00001.php

Version details:
Postgresql 7.4.8
Solaris 10, AMD64
GCC 3.4.3

To my untrained eye, it appears that configure chooses two versions of tas()
for this combination (regardless of 32/64-bitness). I'm trying to determine
whether this is a correct interpretation and if so, which version of tas() of
the correct version to be using with GCC on Solaris.

When building Postgresql on Solaris using GCC, the configure script appears to
link tas.s to tas/solaris_i386.s. This file compiles in 32bit mode, but not
in 64bit (I manually linked to dummy.s when compiling in 64bit). The
following symbols are from the 32bit build.

$ nm src/backend/port/tas.o
00000000 T tas
$ nm src/backend/port/SUBSYS.o | grep tas
00000c90 T tas

In addition to tas.s, configure also enables the proper #defs for the inline
tas() definition in s_lock.h:

--- from line 97 ---
#if defined(__i386__) || defined(__x86_64__) /* AMD Opteron */
#define TAS(lock) tas(lock)

static __inline__ int
tas(volatile slock_t *lock)
{
register slock_t _res = 1;

__asm__ __volatile__(
" lock \n"
" xchgb %0,%1 \n"
: "=q"(_res), "=m"(*lock)
: "0"(_res));
return (int) _res;
}

These three tas symbols included from s_lock.h:

src/backend/storage/lmgr/lwlock.o
000002fa t tas
src/backend/storage/lmgr/proc.o
00000483 t tas
src/backend/storage/lmgr/s_lock.o
0000017b t tas

src/backend/storage/lmgr/SUBSYS.o
000047e2 t tas
0000270b t tas
00004c3b t tas

Thanks for any suggestions or insight,

Michael Crozier

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Tom Lane

2005-09-28, 3:24 am

Michael Crozier < crozierm@conducivete
ch.com> writes:
> I'm again looking at tas/spinlock build problems while investigating unusually
> high CPU usage during load testing. My issue was first mentioned here:

> http://archives.postgresql.org/pgsq...09/msg00001.php

Hmmm ... you really shouldn't be using the out-of-line tas.s code for
gcc-based builds on any common architecture. I think the problem may be
that the case statement in src/template/solaris is testing for "i?86"
which probably doesn't match your x86_64 host. What value does $host
have for you exactly?

> Version details:
> Postgresql 7.4.8

7.4 is not exactly a spring chicken. I suggest that you experiment with
CVS tip (8.1beta) and document what still needs to be fixed. After we
figure that out, we can discuss whether the changes are reasonable to
back-patch to the 7.4 branch --- but starting a portability
investigation with an old branch is a waste of everybody's time.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Michael Crozier

2005-09-28, 8:25 pm

> Hmmm ... you really shouldn't be using the out-of-line tas.s code for
> gcc-based builds on any common architecture.

Thanks, that answers my questions about which TAS code should be in the build.

Both sets of code will be compiled into any solaris 32bit build, but the
inline code should be the code in use. When compiling a 64bit build with GCC
on solaris 10 x86, the out-of-line tas.s code will fail to build and tas.s
must therefore be manually linked to dummy.s.

> I think the problem may be
> that the case statement in src/template/solaris is testing for "i?86"
> which probably doesn't match your x86_64 host.

The 7.4 template is not checking for $GCC before linking tas.s, probably
assuming that any solaris host is using SunCC.

8.0.3 & 8.1beta1 check for !GCC before linking to solaris_i386.s, which is
correct.

Thanks for your help.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly

Sponsored Links