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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-08-24 16:16:24 | Re: 8.0 beta 1 on linux-mipsel R5900 |
Previous Message | Neil Conway | 2004-08-24 14:58:56 | Re: 8.0 beta 1 on linux-mipsel R5900 |