Re: spinlocks on powerpc

On 12/30/2011 11:23 AM, Tom Lane wrote:
> 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.
>
> 			

#3 in particular is unspeakably ugly.

cheers

andrew