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