
> >> Think harder... one processor != one process...
> 
> > Well sure, but you don't want a spinlock in that case.
> 
> Actually you do, when the normal case is that you don't have to block.
> You want it to fall through as quickly as possible in the success case
> (the blocking case is going to suck no matter what).  Given the present
> set of available/portable technologies, spinlocks win.

I guess it could still save some CPU cycles in the single CPU case,
if you yield() instead of tight loop around TAS in the failure case.
Problem is yield and detecting single CPU is not portable.

Andreas

Tue, 24 Aug 2004 10:05:59 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: 8.0 beta 1 on linux-mipsel R5900
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> I guess it could still save some CPU cycles in the single CPU case,
> if you yield() instead of tight loop around TAS in the failure case.
> Problem is yield and detecting single CPU is not portable.

Sure, but that's still a spinlock --- you're just tuning the backoff
behavior for local conditions.

On some architectures (Alpha at least) the TAS instruction can "fail"
even though the lock is free, if an interrupt happens to get in the way.
So I'd be inclined to loop a few times even on a single-CPU machine.

But yes, a yield primitive would be nice, and so would knowing the
number of CPUs.

			regards, tom lane

Tue, 24 Aug 2004 10:35:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 8.0 beta 1 on linux-mipsel R5900 
Tom Lane wrote:
> But yes, a yield primitive would be nice, and so would knowing the
> number of CPUs.

I'm planning on submitting a patch shortly that determines the number of 
CPUs in the machine and adjusts the spinlock behavior accordingly (there 
are various APIs for getting the # of CPUs, like sysctl() on many Unixen 
and GetSystemInfo() on Win32).

Speaking of improving spinlock behavior, there's a Solaris API that I 
think might be worth using: schedctl_start() asks the scheduler to not 
pre-empt the current process, and schedctl_stop() cancels the request. 
The idea the first extremely short periods of time that we're holding a 
spinlock, we don't want to get preempted, since if the process was 
allowed to run for just a little bit longer it would probably give up 
the spinlock. The docs are here:

http://docs.sun.com/db/doc/816-3324/6m9k4vdu1?a=view

-Neil


Tue, 24 Aug 2004 10:58:56 -0400
Neil Conway <neilc@samurai.com>
Re: 8.0 beta 1 on linux-mipsel R5900
Neil Conway <neilc@samurai.com> writes:
> Speaking of improving spinlock behavior, there's a Solaris API that I 
> think might be worth using: schedctl_start() asks the scheduler to not 
> pre-empt the current process, and schedctl_stop() cancels the request. 
> The idea the first extremely short periods of time that we're holding a 
> spinlock, we don't want to get preempted, since if the process was 
> allowed to run for just a little bit longer it would probably give up 
> the spinlock.

Associating such a thing with spinlocks seems certain to be a dead loss,
as the amount of time we normally hold a spinlock is much less than the
time to make one kernel call, let alone two.

Associating it with LWLocks is slightly more plausible.  There are some
LWLocks that are held for lengths of time that would make it reasonable
to do this (but not all of them are used that way, so some thought is
still needed).

On the count-the-number-of-CPUs patch, what sort of coverage are you
expecting to get?  If we could be certain that all SMP-capable platforms
are covered, then we could default to assuming 1 CPU on platforms that
don't have any of those APIs, which would be a win.

			regards, tom lane

Tue, 24 Aug 2004 12:08:40 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 8.0 beta 1 on linux-mipsel R5900 
Tom Lane wrote:
> Associating such a thing with spinlocks seems certain to be a dead loss,
> as the amount of time we normally hold a spinlock is much less than the
> time to make one kernel call, let alone two.

Yeah, I was thinking about this. ISTM the only way that Sun would bother 
to provide an API like this is if it had significantly less overhead 
than a standard system call. Anyway, I'll take a closer look.

> On the count-the-number-of-CPUs patch, what sort of coverage are you
> expecting to get?

I haven't yet seen a platform that doesn't provide some means to get the 
# of CPUs, but I suppose there might be one...

-Neil



Tue, 24 Aug 2004 12:16:24 -0400
Neil Conway <neilc@samurai.com>
Re: 8.0 beta 1 on linux-mipsel R5900
Neil Conway <neilc@samurai.com> writes:
> Tom Lane wrote:
>> On the count-the-number-of-CPUs patch, what sort of coverage are you
>> expecting to get?

> I haven't yet seen a platform that doesn't provide some means to get the 
> # of CPUs, but I suppose there might be one...

It might be worth exposing the CPU count as a GUC variable.  This would
* make it easy to check on the results of the counting patch;
* make it easy to override the patch, if it's wrong on some platform;
* make it easy to experiment to see whether the spinlock behavioral
  change actually matters ;-)

But this may be overkill.

			regards, tom lane

Tue, 24 Aug 2004 13:20:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 8.0 beta 1 on linux-mipsel R5900 
Neil Conway <neilc@samurai.com> writes:

> Tom Lane wrote:
> > Associating such a thing with spinlocks seems certain to be a dead loss,
> > as the amount of time we normally hold a spinlock is much less than the
> > time to make one kernel call, let alone two.
> 
> Yeah, I was thinking about this. ISTM the only way that Sun would bother to
> provide an API like this is if it had significantly less overhead than a
> standard system call. Anyway, I'll take a closer look.

There are ways they could have done this too. It doesn't really need a syscall
since the kernel doesn't need the information until it tries to do a context
switch. The function could merely place the information in a shared memory
page for the kernel to consult when the timer interrupt goes off.

> > On the count-the-number-of-CPUs patch, what sort of coverage are you
> > expecting to get?
> 
> I haven't yet seen a platform that doesn't provide some means to get the # of
> CPUs, but I suppose there might be one...

As Tom mentions, it would be nice to be able to override it. One reason I can
think of is if you're on a machine with many processors but have used admin
tools to bind postgres to just a subset of the processors or even just a
single processor. You would want postgres to behave as if it's a machine with
only those processors.

-- 
greg


24 Aug 2004 17:47:39 -0400
Greg Stark <gsstark@mit.edu>
Re: 8.0 beta 1 on linux-mipsel R5900