Re: [PATCH] Use MAP_HUGETLB where supported (v3)

Поиск
Список
Период
Сортировка
От Abhijit Menon-Sen
Тема Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Дата
Msg-id 20131030072833.GG4183@toroid.org
обсуждение исходный текст
Ответ на Re: [PATCH] Use MAP_HUGETLB where supported (v3)  (David Fetter <david@fetter.org>)
Список pgsql-hackers
At 2013-10-30 00:10:39 -0700, david@fetter.org wrote:
>
> How about documenting that 2MB is the quantum (OK, we'll say
> "indivisible unit" or "smallest division" or something) and failing
> with a message to that effect if someone tries to set it otherwise?

I don't think you understand the problem. We're not discussing a user
setting here. The size that is passed to PGSharedMemoryCreate is based
on shared_buffers and our estimates of how much memory we need for other
things like ProcArray (see ipci.c:CreateSharedMemoryAndSemaphores).

If this calculated size is not a multiple of a page size supported by
the hardware (usually 2/4/16MB etc.), the allocation will fail under
some commonly-used kernels. We can either ignore the problem and let
the allocation fail, or try to discover the smallest supported huge
page size (what the patch does now), or assume that 2MB pages can be
used if any huge pages can be used and align accordingly.

We could use a larger size, e.g. if we aligned to 16MB then it would
work on hardware that supported 2/4/8/16MB pages, but we'd waste the
extra memory unless we also increased NBuffers after the rounding up
(which is also something Andres suggested earlier).

I don't have a strong opinion on the available options, other than not
liking the "do nothing" approach.

-- Abhijit



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Следующее
От: Leonardo Francalanci
Дата:
Сообщение: Re: Fast insertion indexes: why no developments