Re: spinlocks on HP-UX

On Sun, Aug 26, 2012 at 9:45 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Thu, Dec 29, 2011 at 11:37:22AM +0900, Manabu Ori wrote:
>> > > a configure test only proves whether the build machine can deal
>> > > with the flag, not whether the machine the executables will
>> > > ultimately run on knows what the flag means. We cannot assume that
>> > > the build and execution boxes are the same. (In general,
>> > > AC_TRY_RUN tests are best avoided because of this.)
>> >
>> > I understand why that is important in general, but as a shop which
>> > builds from source, and is fine with a separate build for each
>> > hardware model / OS version combination, it would be great if any
>> > optimizations which are only available if you *do* assume that the
>> > build machine and the run machine are the same (or at lease
>> > identical) could be enabled with some configure switch. Maybe
>> > something like --enable-platform-specific-optimizations.
>> >
>> > I don't know if any such possible optimizations currently exist, I'm
>> > just saying that if any are identified, it would be nice to have the
>> > option of using them.
>>
>> I can't say the right way to go for now, but I'd like binary
>> packages could enjoy the effect of my patch as far as possible so
>> that I made lwarx hint test run in configure runtime.
>
> Was there any conclusion to this discussion?

I don't think so. Broadly, I'm skeptical of hints. The CPU already
does prefetching, so there is value in hints only if we can be smarter
than the CPU. That's kind of an iffy proposition, particularly since
different CPUs have very different behavior. What may be a good idea
on one platform can stink on another platform. Also, something that
works well in low-contention situations can blow up in high-contention
situations, and visca versa. Consider this typical sequence:

- prefetch something
- do a little bit of other work
- use the thing we prefetched

If the system isn't under heavy contention, this can be a big win.
The work is overlayed with the prefetch, so that by the time we get to
step 3, we don't have to wait. But if the system now becomes
contended, the prefetch may grab the cache line that we need, and then
some other process may steal it, and then in step 3 we have to steal
it back. So now our huge win becomes a huge loss, because we're
fetching the same cache lines twice per backend instead of once. Now
you can (maybe) fix this by jiggering the amount of other work that
you do in between the prefetch and the usage, but that's likely to be
different on every architecture, so the whole thing feels like a
fairly impossible problem.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company