Re: [PATCH] Use MAP_HUGETLB where supported (v3) - Mailing list pgsql-hackers

From Abhijit Menon-Sen
Subject Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Date
Msg-id 20131030044657.GD4183@toroid.org
Whole thread Raw
In response to Re: [PATCH] Use MAP_HUGETLB where supported (v3)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: [PATCH] Use MAP_HUGETLB where supported (v3)  (David Fetter <david@fetter.org>)
Re: [PATCH] Use MAP_HUGETLB where supported (v3)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)