From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Michael Paesold" <mpaesold(at)gmx(dot)at> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: Spinlocks, yet again: analysis and proposed patches |
Date: | 2005-09-12 18:48:27 |
Message-ID: | 23617.1126550907@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Michael Paesold" <mpaesold(at)gmx(dot)at> writes:
> It seems to me the slock-no-cmpb is a win in any case. The spin-delay patch
> does not really help much on this machine. That seems to match Stephen
> Frost's results with EM64T, if I read them correctly.
Yeah, it's interesting that you both see slock-no-cmpb as saving some
cycles and the second patch as giving them back. I wonder whether the
integer-modulo-to-slow-the-loop trick is counterproductive on your
machines. You both seem to be using hardware that will recognize
rep;nop and maybe that's all that's needed.
I probably should have broken down the spindelay patch into multiple
components. But it's only a small change --- could you try simplifying
the patched line
if ((--spins % MAX_SPINS_PER_DELAY) == 0)
to
if (--spins == 0)
and see how the patch does that way?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paesold | 2005-09-12 19:12:50 | Re: Spinlocks, yet again: analysis and proposed patches |
Previous Message | Michael Paesold | 2005-09-12 18:37:54 | Re: Spinlocks, yet again: analysis and proposed patches |