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
On Tue, Jan 3, 2012 at 3:05 PM, Jeremy Harris j...@wizmail.org 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 3, 2012 at 3:05 PM, Jeremy Harris j...@wizmail.org 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).
Robert Haas robertmh...@gmail.com 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
On Tue, Jan 3, 2012 at 4:17 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Jan 2, 2012 at 12:03 AM, Tom Lane t...@sss.pgh.pa.us 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
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
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
Manabu Ori manabu@gmail.com 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
Manabu Ori manabu@gmail.com writes:
2011/12/30 Tom Lane t...@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
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.
On 12/30/2011 11:23 AM, Tom Lane wrote:
Manabu Orimanabu@gmail.com writes:
2011/12/30 Tom Lanet...@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
2011/12/30 Tom Lane t...@sss.pgh.pa.us
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
13 matches
Mail list logo
