public inbox for [email protected]  

help / color / mirror / Atom feed
From: Michael Paquier <[email protected]>
To: Bossart, Nathan <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Magnus Hagander <[email protected]>
Cc: Mark Dilger <[email protected]>
Cc: Don Seiler <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Estimating HugePages Requirements?
Date: Thu, 2 Sep 2021 16:50:52 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Wed, Sep 01, 2021 at 06:28:21PM +0000, Bossart, Nathan wrote:
> On 8/31/21, 11:54 PM, "Michael Paquier" <[email protected]> wrote:
>> Hmm.  I am not sure about the addition of huge_pages_required, knowing
>> that we would have shared_memory_size.  I'd rather let the calculation
>> part to the user with a scan of /proc/meminfo.
> 
> I included this based on some feedback from Andres upthread [0].  I
> went ahead and split the patch set into 3 pieces in case we end up
> leaving it out.

Thanks.  Anyway, we don't really need huge_pages_required on Windows,
do we?  The following docs of Windows tell what do to when using large
pages:
https://docs.microsoft.com/en-us/windows/win32/memory/large-page-support

The backend code does that as in PGSharedMemoryCreate(), now that I
look at it.  And there is no way to change the minimum large page size
there as far as I can see because that's decided by the processor, no?
There is a case for shared_memory_size on Windows to be able to adjust
the sizing of the memory of the host, though.

>> +#elif defined(WIN32)
>> +   hp_size = GetLargePageMinimum();
>> +#endif
>> +
>> +#if defined(MAP_HUGETLB) || defined(WIN32)
>> +   hp_required = (size_b / hp_size) + 1;
>> As of [1], there is the following description:
>> "If the processor does not support large pages, the return value is
>> zero."
>> So there is a problem here.
> 
> I've fixed this in v4.

At the end it would be nice to not finish with two GUCs.  Both depend
on the reordering of the actions done by the postmaster, so I'd be
curious to hear the thoughts of others on this particular point.
--
Michael


Attachments:

  [application/pgp-signature] signature.asc (833B, 2-signature.asc)
  download

view thread (108+ messages)  latest in thread

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Estimating HugePages Requirements?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox