Re: Estimating HugePages Requirements? - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Estimating HugePages Requirements?
Date
Msg-id 578A8F79-FD13-4408-865F-4D31EE5D8123@amazon.com
Whole thread Raw
In response to Re: Estimating HugePages Requirements?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Estimating HugePages Requirements?
List pgsql-hackers
On 9/6/21, 9:00 PM, "Michael Paquier" <michael@paquier.xyz> wrote:
> +   sprintf(buf, "%lu MB", size_mb);
> +   SetConfigOption("shared_memory_size", buf, PGC_INTERNAL, PGC_S_OVERRIDE);
> One small-ish comment about 0002: there is no need to add the unit
> into the buffer set as GUC_UNIT_MB would take care of that.  The patch
> looks fine.

I fixed this in v7.

> +#ifndef WIN32
> +#include <sys/mman.h>
> +#endif
> So, this is needed in ipci.c to check for MAP_HUGETLB.  I am not much
> a fan of moving around platform-specific checks when these have
> remained local to each shmem implementation.  Could it be cleaner to
> add GetHugePageSize() to win32_shmem.c and make it always declared in
> the SysV implementation?

I don't know if it's really all that much cleaner, but I did it this
way in v7.  IMO it's a little weird that GetHugePageSize() doesn't
return the value from GetLargePageMinimum(), but that's what we'd need
to do to avoid setting huge_pages_required for Windows without any
platform-specific checks.

Nathan


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Estimating HugePages Requirements?