Re: [PATCH] Use MAP_HUGETLB where supported (v3)
От | Abhijit Menon-Sen |
---|---|
Тема | Re: [PATCH] Use MAP_HUGETLB where supported (v3) |
Дата | |
Msg-id | 20131030044657.GD4183@toroid.org обсуждение исходный текст |
Ответ на | Re: [PATCH] Use MAP_HUGETLB where supported (v3) (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Re: [PATCH] Use MAP_HUGETLB where supported (v3) |
Список | pgsql-hackers |
At 2013-10-24 16:06:19 +0300, hlinnakangas@vmware.com wrote: > > Let's get rid of the rounding. I share Andres's concern that the bug is present in various recent kernels that are going to stick around for quite some time. Given the rather significant performance gain, I think it's worth doing something, though I'm not a big fan of the directory-scanning code myself. As a compromise, perhaps we can unconditionally round the size up to be a multiple of 2MB? That way, we can use huge pages more often, but also avoid putting in a lot of code and effort into the workaround and waste only a little space (if any at all). > Other comments: > > * guc.c doesn't actually need sys/mman.h for anything. Getting rid > of the #include also lets you remove the configure test. You're right, guc.c doesn't use it any more; I've removed the #include. sysv_shmem.c does use it (MAP_*, PROT_*), however, so I've left the test in configure alone. I see that sys/mman.h is included elsewhere with an #ifdef WIN32 or HAVE_SHM_OPEN guard, but HAVE_SYS_MMAN_H seems better. > * the documentation should perhaps mention that the setting only has > an effect if POSIX shared memory is used. As Robert said, this is not correct, so I haven't changed anything. -- Abhijit
В списке pgsql-hackers по дате отправления: