Re: spinlocks on powerpc - Mailing list pgsql-hackers

From Tom Lane
Subject Re: spinlocks on powerpc
Date
Msg-id 17831.1325262194@sss.pgh.pa.us
Whole thread Raw
In response to spinlocks on powerpc  (Manabu Ori <manabu.ori@gmail.com>)
Responses Re: spinlocks on powerpc  (Andrew Dunstan <andrew@dunslane.net>)
Re: spinlocks on powerpc  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Manabu Ori <manabu.ori@gmail.com> writes:
> 2011/12/30 Tom Lane <tgl@sss.pgh.pa.us>
>> The info that I've found says that the hint exists beginning in POWER6,
>> and there were certainly 64-bit Power machines before that.  However,
>> it might be that the only machines that actually spit up on the hint bit
>> (rather than ignore it) were 32-bit, in which case this would be a
>> usable heuristic.  Not sure how we can research that ... do we want to
>> just assume the kernel guys know what they're doing?

> I'm a bit confused and might miss the point, but...

> If we can decide whether to use the hint operand when we build
> postgres, I think it's better to check if we can compile and run
> a sample code with lwarx hint operand than to refer to some
> arbitrary defines, such as FOO_PPC64 or something.

Well, there are two different conditions we have to deal with:

(1) does gcc+assembler understand the hint operand for lwarx?
This we can reasonably check with configure, since it's a property
of the build environment.

(2) does the machine where the executable will run understand the
hint bit, or failing that at least treat it as a no-op?  We cannot
determine that at configure time, unless we can fall back on some
approximate proxy condition like testing 64-bit vs 32-bit.

(I see that the kernel boys dodged point 1 by writing the lwarx
instruction as a numeric constant, but that seems far too ugly
and fragile for my taste.  In any case point 2 is the big issue.)

If you don't like the 64-bit hack or something much like it,
I think we have got three other alternatives:

* Do nothing, ie reject the patch.

* Push the problem onto the user by offering a configure option.
I don't care for this in the least, notably because packagers
such as Linux distros couldn't safely enable the option, so in
practice it would be unavailable to a large fraction of users.

* Perform a runtime test.  I'm not sure if there's a better way,
but if nothing else we could fork a subprocess during postmaster
start, have it try an lwarx with hint bit, observe whether it dumps
core, and set a flag to tell future TAS calls whether to use the hint
bit.  Ick.  In any case, adding a conditional branch to the TAS code
would lose some of the performance benefit of the patch.  Given that
you don't get any benefit at all until you have a large number of
cores, this would be a net loss for a lot of people.

None of those look better than an approximate proxy condition
to me.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Aidan Van Dyk
Date:
Subject: Re: 16-bit page checksums for 9.2
Next
From: Peter Eisentraut
Date:
Subject: Re: spinlocks on powerpc