On Tue, Jan 3, 2012 at 4:17 PM, Tom Lane wrote:
>> For Itanium, I was able to find some fairly official-looking
>> documentation that said "this is how you should do it". It would be
>> nice to find something similar for PPC64, instead of testing every
>> machine and reinventing the wheel ourselv
Robert Haas writes:
> I'm unconvinced by these numbers. There is a measurable change but it
> is pretty small. The Itanium changes resulted in an enormous gain at
> higher concurrency levels.
Yeah, that was my problem with it also: I couldn't measure enough gain
to convince me it was a real eff
Robert Haas writes:
> On Tue, Jan 3, 2012 at 3:05 PM, Jeremy Harris wrote:
>> Also, heavy-contention locks should be placed in cache lines away from other
>> data (to avoid thrashing the data cache lines when processors are fighting
>> over the lock cache lines).
> Yep. This is possibly a probl
On Tue, Jan 3, 2012 at 3:05 PM, Jeremy Harris wrote:
> On 2012-01-03 04:44, Robert Haas wrote:
>> On read-only workloads, you get spinlock contention, because everyone
>> who wants a snapshot has to take the LWLock mutex to increment the
>> shared lock count and again (just a moment later) to decr
On 2012-01-03 04:44, Robert Haas wrote:
On read-only workloads, you get spinlock contention, because everyone
who wants a snapshot has to take the LWLock mutex to increment the
shared lock count and again (just a moment later) to decrement it.
Does the LWLock protect anything but the shared loc
On Mon, Jan 2, 2012 at 12:03 AM, Tom Lane wrote:
> (It's depressing that these numbers have hardly moved since August ---
> at least on this test, the work that Robert's done has not made any
> difference.)
Most of the scalability work that's been committed since August has
really been about Proc
Manabu Ori writes:
> I recreated the patch as you advised.
Hmm, guess I wasn't clear --- we still need a configure test, since even
if we are on PPC64 there's no guarantee that the assembler will accept
the hint bit.
I revised the patch to include a configure test and committed it.
However, I om
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__)
> #define USE_PPC_LWARX_MUTEX_HINT
>
I wrote:
> 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 did a bit of re
On 12/30/2011 11:23 AM, Tom Lane wrote:
Manabu Ori writes:
2011/12/30 Tom Lane
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 bi
On fre, 2011-12-30 at 14:47 +0900, Manabu Ori wrote:
> 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.
Manabu Ori writes:
> 2011/12/30 Tom Lane
>> 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
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 shoul
13 matches
Mail list logo
