Re: [HACKERS] spinlocks on powerpc

2012-01-01 Thread Manabu Ori
Tom, thank you for your advise.

On 2012/01/01, at 3:39, Tom Lane wrote:

 What I suggest we should do about this is provide an overridable option
 in pg_config_manual.h, along the lines of
   #if defined(__ppc64__) || defined(__powerpc64__)
 and then test that symbol in s_lock.h.  This will provide an escape
 hatch for anyone who doesn't want the decision tied to 64-bit-ness,
 while still enabling the option automatically for the majority of
 people who could use it.

Fair enough.
I recreated the patch as you advised.

Description: Binary data

 BTW, while reading the ISA document I couldn't help noticing that LWARX
 is clearly specified to operate on 4-byte quantities (there's LDARX if
 you want to use 8-byte).  Which seems to mean that this bit in s_lock.h
 just represents bogus waste of space:
 #if defined(__ppc64__) || defined(__powerpc64__)
 typedef unsigned long slock_t;
 typedef unsigned int slock_t;
 Shouldn't we just make slock_t be int for both PPC and PPC64?

I'd like it to be untouched for this TAS_SPIN for powerpc
discussion, since it seems it remainds like this for several
years and maybe it needs some more careful consideration
especially for sign extension…

Manabu Ori
Sent via pgsql-hackers mailing list (
To make changes to your subscription:

[HACKERS] spinlocks on powerpc

2011-12-29 Thread Manabu Ori
2011/12/30 Tom Lane
 Heikki Linnakangas writes:
  The Linux kernel does this (arch/powerpc/include/asm/ppc-opcode.h):

 Yeah, I was looking at that too.

  We can't copy-paste code from Linux directly, and I'm not sure I like
  that particular phrasing of the macro, but perhaps we should steal the
  idea and only use the hint on 64-bit PowerPC processors?

 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.

I still wonder when to judge the hint availability, compile time
or runtime.
I don't have any idea how to decide that on runtime, though.

I changed the subject since it's no longer related to HPUX.

Manabu Ori

Re: [HACKERS] spinlocks on HP-UX

2011-12-28 Thread Manabu Ori
2011/12/29 Tatsuo Ishii
  Impressive results.
  config/c-compiler.m4 doesn't seem like the right place for the
  configure test. Would there be any harm in setting the lwarx hint
  always; what would happen on older ppc processors that don't support

 I think the load module just fails to run in this case, but I'd like
 to confirm. Ori-san?

I don't know where is the right config/*.m4 to place this kind of
configure test. Do you have any idea?

I believe lwarx hint would be no harm for recent PowerPC processors.
What I tested are:

  (1) Built postgres on POWER6 + RHEL5, which got lwarx hint
  included. Then copy these src tree to POWER5 + RHEL4 and
  run make test, finished successfully.

  (2) Lwarx test in configure failed on POWER5 + RHEL4.

Note that POWER6 understands lwarx hint and POWER5 doesn't.
RHEL5 binutils supports lwarx hint and RHEL4 binutils doesn't.

The only concern is for very old PowerPC.
Referring to Power Instruction Set Architecture manual(*1), on
some processors that precede PowerISA v2.00, executing lwarx with
hint will cause the illegal instruction error.

Lwarx test in configure should fail on these kind of processors,
guessing from my test(2).

(*1) p.689 of

Manabu Ori

Re: [HACKERS] spinlocks on HP-UX

2011-12-28 Thread Manabu Ori
  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.

Manabu Ori