Date: Tue, 26 Apr 2022 10:34:06 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Magnus Hagander <magnus@hagander.net>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
	"Bossart, Nathan" <bossartn@amazon.com>,
	Fujii Masao <masao.fujii@oss.nttdata.com>,
	Justin Pryzby <pryzby@telsasoft.com>,
	Andres Freund <andres@anarazel.de>,
	Mark Dilger <mark.dilger@enterprisedb.com>,
	Don Seiler <don@seiler.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Estimating HugePages Requirements?
Message-ID: <YmdMDiCCyVJLlB/F@paquier.xyz>
References: <20220314173417.GA1020555@nathanxps13>
 <Yi/82cqnpKkZsOjI@paquier.xyz>
 <CABUevExgoKMNveD5SvFWOYA4MQvPkDmGxY7DkVRASJED4gBYog@mail.gmail.com>
 <20220315224439.GA1133771@nathanxps13>
 <Yjq9bJe28newGZaK@paquier.xyz>
 <CABUevEyExSDrtZ4wU19iX4yvgExR1EpjFKB4ExFQDgTAvAHFyg@mail.gmail.com>
 <Yl8z169DzkSjdZFV@paquier.xyz>
 <CABUevEwPPxR-SD55UWDLZuLa2UVGY+OQpVPPvO82X10MU_hLcA@mail.gmail.com>
 <YmXoIEaR2CWRV7KP@paquier.xyz>
 <CABUevEyD_aLM=oXi1jj8hRN=7aJq--jN4FP+ehY8Vu60+QH61A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="msaMHsBC5Obpi/IC"
Content-Disposition: inline
In-Reply-To: 
 <CABUevEyD_aLM=oXi1jj8hRN=7aJq--jN4FP+ehY8Vu60+QH61A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/YmdMDiCCyVJLlB/F%40paquier.xyz>
Precedence: bulk


--msaMHsBC5Obpi/IC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 25, 2022 at 04:55:25PM +0200, Magnus Hagander wrote:
> AIUI that was the original use-case for this feature. It certainly was for
> me :)

Perhaps we'd be fine with relaxing the requirements here knowing that
the control file should never be larger than PG_CONTROL_MAX_SAFE_SIZE
(aka the read should be atomic so it could be made lockless).  At the
end of the day, to be absolutely correct in the shmem size estimation,
I think that we are going to need what's proposed here or the sizing
may not be right depending on how extensions adjust GUCs after they
load their _PG_init():
https://www.postgresql.org/message-id/20220419154658.GA2487941@nathanxps13

That's a bit independent, but not completely unrelated either
depending on how exact you want your number of estimated huge pages to
be.  Just wanted to mention it.

>> Contrary to Linux, we don't need to care about the number of large
>> pages that are necessary because there is no equivalent of
>> vm.nr_hugepages on Windows (see [1]), do we?  If that were the case,
>> we'd have a use case for huge_page_size, additionally.
>=20
> Right, for this one in particular -- that's what I meant with my comment
> about there not being a limit. But this feature works for other settings =
as
> well, not just the huge pages one.  Exactly what the use-cases are can
> vary, but surely they would have the same problems wrt redirects?

Yes, the redirection issue would apply to all the run-time GUCs.
--
Michael

--msaMHsBC5Obpi/IC
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmJnTA4ACgkQnvQgOdby
QH2HIA//WiWypCuaNly1taL+p0tZcdFekFunaCT3txASuCJd3U639ypfjSY1tFMo
ZQcZU37R0qM7VXrqoKlUibPuK+UmrpoxgRa04TqXzpkhyK3OgCzJUOOzmBTXkGlO
IT4M8sRX1OUQp96nDqTuVdxEySTJ9FvBARry3lsah+2Nm0mhMKOa9c9HzVwSiFKm
AKEF0DBPqUC2j8wG5pnibuKbwuIf9cA3oxm0888LkS47qM6/8Ic4f1KRppqz3fhE
ehZvTN/IkGthuwcH6P9vQGW9EOwesMwEKAbbMsr49YvomEOYV3nHFvil8LgL9G5E
6ciDNJ/V43tcIHR5lfFr/TKSriNQqw0ojL8ft9jgq1vQbrNwRs7bEf+B7tjz0n4n
hjEpproNNfs0T+MvLWz4FcovthmAuCse2K/DDTwfUPCDACK+7f5/FPIfI3wmvb/t
XPDxR6FeAezio61oGnylJtpuJfD5zkNifKmIcOolfO4l4wQneK7pNbqr7bBM1Uj3
JHoMBu0uioCp12UuWMHVKiTK58mSMWsjNSNrrPNTsycY/Hthy7iAXdkqNYLz4zwQ
ik8yf7LW7tO/e4+REZIYoxI+ZkG78SkbR5hpxvtYsccRaIfV0IlW6OFl7t36LITa
mpsMh1pQHkrXL7gDbcoiYIJVTJiIzy8xdYirT4BflFYQewWbCFw=
=1xWk
-----END PGP SIGNATURE-----

--msaMHsBC5Obpi/IC--