Re: spinlocks on powerpc - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: spinlocks on powerpc |
Date | |
Msg-id | 4EFDEA19.5040201@dunslane.net Whole thread Raw |
In response to | Re: spinlocks on powerpc (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
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
pgsql-hackers by date: