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 по дате отправления:

Предыдущее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: PG replic refs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] server crash in very big transaction [postgresql 8.0beta1]