Dave,
> But... you need a baseline first.
A baseline on CS? I have that
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Josh,
I think you can safely increase by orders of magnitude here, instead of
by +100, my wild ass guess is that the sweet spot is the spin time
should be approximately the time it takes to consume the resource. So if
you have a really fast machine then the spin count should be higher.
Also you
Dave,
> Are you testing this with Tom's code, you need to do a baseline
> measurement with 10 and then increase it, you will still get lots of cs,
> but it will be less.
No, that was just a test of 1000 straight up.Tom outlined a method, but I
didn't see any code that would help me find a be
Are you testing this with Tom's code, you need to do a baseline
measurement with 10 and then increase it, you will still get lots of cs,
but it will be less.
Dave
On Mon, 2004-04-26 at 20:03, Josh Berkus wrote:
> Dave,
>
> > Yeah, I did some more testing myself, and actually get better numbers
>
Dave,
> Yeah, I did some more testing myself, and actually get better numbers
> with increasing spins per delay to 1000, but my suspicion is that it is
> highly dependent on finding the right delay for the processor you are
> on.
Well, it certainly didn't help here:
procs me
On Thu, 2004-04-22 at 10:37 -0700, Josh Berkus wrote:
> Tom,
>
> > The tricky
> > part is that a slow adaptation rate means we can't have every backend
> > figuring this out for itself --- the right value would have to be
> > maintained globally, and I'm not sure how to do that without adding a
>
On Thu, 2004-04-22 at 13:55, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > This may be a moot point, since you've stated that changing the loop timing
> > won't solve the problem, but what about making the test part of make? I
> > don't think too many systems are going to change
>> Having to recompile to run on single- vs dual-processor
>machines doesn't
>> seem like it would fly.
>
>Oh, I don't know. Many applications require compiling for a target
>architecture; SQL Server, for example, won't use a 2nd
>processor without
>re-installation. I'm not sure about Oracle
Tom,
> The tricky
> part is that a slow adaptation rate means we can't have every backend
> figuring this out for itself --- the right value would have to be
> maintained globally, and I'm not sure how to do that without adding a
> lot of overhead.
This may be a moot point, since you've stated th
Josh Berkus <[EMAIL PROTECTED]> writes:
> This may be a moot point, since you've stated that changing the loop timing
> won't solve the problem, but what about making the test part of make? I
> don't think too many systems are going to change processor architectures once
> in production, and th
Tom,
> Having to recompile to run on single- vs dual-processor machines doesn't
> seem like it would fly.
Oh, I don't know. Many applications require compiling for a target
architecture; SQL Server, for example, won't use a 2nd processor without
re-installation. I'm not sure about Oracle.
I
Josh Berkus wrote:
> Tom,
>
> > Having to recompile to run on single- vs dual-processor machines doesn't
> > seem like it would fly.
>
> Oh, I don't know. Many applications require compiling for a target
> architecture; SQL Server, for example, won't use a 2nd processor without
> re-installati
Dave Cramer <[EMAIL PROTECTED]> writes:
> My hypothesis is that if you spin approximately the same or more time
> than the average time it takes to get finished with the shared resource
> then this should reduce cs.
The only thing we use spinlocks for nowadays is to protect LWLocks, so
the "averag
More data
On a dual xeon with HTT enabled:
I tried increasing the NUM_SPINS to 1000 and it works better.
NUM_SPINLOCKS CS ID pgbench
100 250K59% 230 TPS
1000125K55% 228 TPS
This is certainly heading in the right direction ? Although it lo
Yeah, I did some more testing myself, and actually get better numbers
with increasing spins per delay to 1000, but my suspicion is that it is
highly dependent on finding the right delay for the processor you are
on.
My hypothesis is that if you spin approximately the same or more time
than the ave
Bruce Momjian <[EMAIL PROTECTED]> writes:
> For BSDOS it has:
> #if (CLIENT_OS == OS_FREEBSD) || (CLIENT_OS == OS_BSDOS) || \
> (CLIENT_OS == OS_OPENBSD) || (CLIENT_OS == OS_NETBSD)
> { /* comment out if inappropriate for your *bsd - cyp (25/may/1999) */
> int ncpus; size_t l
Tom Lane wrote:
> Dave Cramer <[EMAIL PROTECTED]> writes:
> > I tried increasing the NUM_SPINS to 1000 and it works better.
>
> Doesn't surprise me. The value of 100 is about right on the assumption
> that the spinlock instruction per se is not too much more expensive than
> any other instruction
Yeah. I don't know a reasonable way to tune this number automatically
for particular systems ... but at the very least we'd need to find a way
to distinguish uniprocessor from multiprocessor, because on a
uniprocessor the optimal value is surely 1.
From TODO:
* Add code to detect an SMP machine a
Dave Cramer <[EMAIL PROTECTED]> writes:
> I tried increasing the NUM_SPINS to 1000 and it works better.
Doesn't surprise me. The value of 100 is about right on the assumption
that the spinlock instruction per se is not too much more expensive than
any other instruction. What I was seeing from op
Dave Cramer <[EMAIL PROTECTED]> writes:
> diff -c -r1.16 s_lock.c
> *** backend/storage/lmgr/s_lock.c 8 Aug 2003 21:42:00 - 1.16
> --- backend/storage/lmgr/s_lock.c 21 Apr 2004 20:27:34 -
> ***
> *** 76,82
>* The select() delays are measured in centise
attached.
--
Dave Cramer
519 939 0336
ICQ # 14675561
Index: backend/storage/lmgr/s_lock.c
===
RCS file: /usr/local/cvs/pgsql-server/src/backend/storage/lmgr/s_lock.c,v
retrieving revision 1.16
diff -c -r1.16 s_lock.c
*** backend/stora
21 matches
Mail list logo
