Date: Thu, 30 Dec 2021 21:55:17 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: stable@freebsd.org Subject: Re: What is FreeBSD 12 equivalent to Linux' "sysctl -w vm.nr_hugepages=1280"? Message-ID: <Yc4OpaNlFRLQiK2R@kib.kiev.ua> In-Reply-To: <Yc4FRqjl76TqrRn/@elch.exwg.net> References: <431b35b0-7745-d2d7-ab04-bbf76e58608a@FreeBSD.org> <Yc3Ww5auxhigef5n@elch.exwg.net> <Yc3bhKj%2BrcVXS%2BfT@kib.kiev.ua> <Yc4FRqjl76TqrRn/@elch.exwg.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 30, 2021 at 08:15:18PM +0100, Christoph Moench-Tegeder wrote:
> 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".
It already is. The only known issue is that the largepages stuff is
not documented.
MFD_HUGETLB is emulated using shm largepages stuff.
>
> 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
We do not reserve anything. Largepage shm needs to be truncated to
desired size before mapping, at which time the contigous physical
memory chunks of right alignment are allocated. There are policy flags
SHM_LARGEPAGE_ALLOC_XXX which specify how hard kernel should try to
defrag if there is no suitable contigous memory.
> with Linux Transparent Huge Pages mechanism (background compaction/
> migration etc.).
This should be similar to our transparent superpages, which has no
relations to largepage stuff. Same as in Linux, I suppose.
> 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 ?
I remember seeing this paper some time ago.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Yc4OpaNlFRLQiK2R>