Date: Thu, 30 Dec 2021 20:15:18 +0100 From: Christoph Moench-Tegeder <cmt@burggraben.net> To: stable@freebsd.org Subject: Re: What is FreeBSD 12 equivalent to Linux' "sysctl -w vm.nr_hugepages=1280"? Message-ID: <Yc4FRqjl76TqrRn/@elch.exwg.net> In-Reply-To: <Yc3bhKj%2BrcVXS%2BfT@kib.kiev.ua> References: <431b35b0-7745-d2d7-ab04-bbf76e58608a@FreeBSD.org> <Yc3Ww5auxhigef5n@elch.exwg.net> <Yc3bhKj%2BrcVXS%2BfT@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
## Konstantin Belousov (kostikbel@gmail.com):
> > There is no equivalent setting on FreeBSD (as of yet), and there's
> > no way to explicitely request huge pages (super pages, large pages,
> > whatever you call them) on FreeBSD in the mmap()/shmget() interfaces
> > (as there is in Linux) (there is MAP_ALIGNED_SUPER in FreeBSD to
> > "maximize the potential use of large (“super”) pages", but from the
> > desription alone that looks like slightly different semantics - and
> > based on how I read those sementics, that randomX code in question
> > should either have a fallback or avoid large pages on any BSD).
>
> I have no idea what the referenced setting does on Linux. Reply
> below is about 'explicitly request large pages'. This is not true.
I was talking about "via mmap()/shmget() as in Linux", where you can
request large ("huge") pages by setting MAP_HUGETLB/SHM_HUGETLB in
the flags argument. We do not have that flag value.
> There is shm_create_largepages() function which returns fd referencing
> shm segment. This segment mappings are guaranteed to be backed by large
> pages of the requested size. More, you cannot split them into mappings
> backed by smaller pages, so e.g. mprotect() or munmap() would only work
> on the chosen superpage size boundary.
Hey, that's a great thing to have. Is that supposed to be part of
our official interface? I can't find any manpage on that.
I only knew about MAP_ALIGNED_SUPER and memfd_create() MFD_HUGETLB
"This flag is currently unsupported".
On Linux, the sysctl vm.nr_hugepages sets the minimun size of the
huge page pool, that is the number of pre-reserved pages of the
default huge page size (2MB on x86-like), and those pages will
be used for {MAP,SHM}_HUGETLB allocations - they are not used for
"normal" usage, that is, if you set nr_hugepages too high, you will
be out of memory very quickly. That thing is not to be confused
with Linux Transparent Huge Pages mechanism (background compaction/
migration etc.).
As you're working in that area - did you see "A Comprehensive Analysis
of Superpage Management Mechanisms and Policies"
https://www.usenix.org/conference/atc20/presentation/zhu-weixi ?
Regards,
Christoph
--
Spare Space
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Yc4FRqjl76TqrRn/>