Re: 8.0 beta 1 on linux-mipsel R5900
От | Tom Lane |
---|---|
Тема | Re: 8.0 beta 1 on linux-mipsel R5900 |
Дата | |
Msg-id | 4477.1093363720@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 8.0 beta 1 on linux-mipsel R5900 (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: 8.0 beta 1 on linux-mipsel R5900
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: