Skip site navigation (1) Skip section navigation (2)

Re: 8.0 beta 1 on linux-mipsel R5900

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>,Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 8.0 beta 1 on linux-mipsel R5900
Date: 2004-08-24 16:08:40
Message-ID: 4477.1093363720@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Neil Conway <neilc(at)samurai(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Neil ConwayDate: 2004-08-24 16:16:24
Subject: Re: 8.0 beta 1 on linux-mipsel R5900
Previous:From: Neil ConwayDate: 2004-08-24 14:58:56
Subject: Re: 8.0 beta 1 on linux-mipsel R5900

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group