Re: Spinlocks, yet again: analysis and proposed patches

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

In response to

Responses

Browse pgsql-hackers by date

  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