Re: MMAP Buffers

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: MMAP Buffers
Дата
Msg-id 24855.1303055336@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: MMAP Buffers  (Radosław Smogura <rsmogura@softperience.eu>)
Ответы Re: MMAP Buffers  (Radosław Smogura <rsmogura@softperience.eu>)
Re: MMAP Buffers  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Radosław Smogura <rsmogura@softperience.eu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> Sunday 17 April 2011 01:35:45
>> ... Huh?  Are you saying that you ask the kernel to map each individual
>> shared buffer separately?  I can't believe that's going to scale to
>> realistic applications.

> No, I do 
> mrempa(mmap_buff_A, MAP_FIXED, temp); 
> mremap(shared_buff_Y, MAP_FIXED, mmap_buff_A), 
> mrempa(tmp, MAP_FIXED, mmap_buff_A). 

There's no mremap() in the Single Unix Spec, nor on my ancient HPUX box,
nor on my quite-up-to-date OS X box.  The Linux man page for it says
"This call is Linux-specific, and should not be used in programs
intended to be portable."  So if the patch is dependent on that call,
it's dead on arrival from a portability standpoint.

But in any case, you didn't explain how use of mremap() avoids the
problem of the kernel having to maintain a separate page-mapping-table
entry for each individual buffer.  (Per process, yet.)  If that's what's
happening, it's going to be a significant performance penalty as well as
(I suspect) a serious constraint on how many buffers can be managed.
        regards, tom lane


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Formatting Curmudgeons WAS: MMAP Buffers
Следующее
От: Tom Lane
Дата:
Сообщение: The big picture for patch submission (was Re: MMAP Buffers)