From nobody Thu Dec 30 19:15:18 2021 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F3054191CC75 for ; Thu, 30 Dec 2021 19:15:21 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from smtp.burggraben.net (smtp.burggraben.net [IPv6:2a01:4f8:140:510a::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.burggraben.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPyf066X2z4sL8 for ; Thu, 30 Dec 2021 19:15:20 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from elch.exwg.net (elch.exwg.net [IPv6:2001:470:7120:1:127b:44ff:fe4f:148d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "elch.exwg.net", Issuer "R3" (not verified)) by smtp.burggraben.net (Postfix) with ESMTPS id E4BB7C011E0 for ; Thu, 30 Dec 2021 20:15:18 +0100 (CET) Received: by elch.exwg.net (Postfix, from userid 1000) id 430FD3AB09; Thu, 30 Dec 2021 20:15:18 +0100 (CET) Date: Thu, 30 Dec 2021 20:15:18 +0100 From: Christoph Moench-Tegeder To: stable@freebsd.org Subject: Re: What is FreeBSD 12 equivalent to Linux' "sysctl -w vm.nr_hugepages=1280"? Message-ID: Mail-Followup-To: stable@freebsd.org References: <431b35b0-7745-d2d7-ab04-bbf76e58608a@FreeBSD.org> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.1.4 (2021-12-11) X-Rspamd-Queue-Id: 4JPyf066X2z4sL8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of cmt@burggraben.net designates 2a01:4f8:140:510a::3 as permitted sender) smtp.mailfrom=cmt@burggraben.net X-Spamd-Result: default: False [-2.29 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[cmt]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:140:510a::3]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[burggraben.net]; RCVD_IN_DNSWL_MED(-0.20)[2a01:4f8:140:510a::3:from]; NEURAL_HAM_SHORT(-0.79)[-0.792]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N 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