From nobody Thu Dec 30 16:17:08 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 6B5991926F65 for ; Thu, 30 Dec 2021 16:17:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPthX4263z4Vr6 for ; Thu, 30 Dec 2021 16:17:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 1BUGH84C020362 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 30 Dec 2021 18:17:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1BUGH84C020362 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1BUGH8l0020361 for stable@freebsd.org; Thu, 30 Dec 2021 18:17:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 30 Dec 2021 18:17:08 +0200 From: Konstantin Belousov To: stable@freebsd.org Subject: Re: What is FreeBSD 12 equivalent to Linux' "sysctl -w vm.nr_hugepages=1280"? Message-ID: 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: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4JPthX4263z4Vr6 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [1.41 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_ONE(0.00)[1]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_SHORT(0.91)[0.907]; NEURAL_SPAM_LONG(0.49)[0.493]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Thu, Dec 30, 2021 at 04:56:51PM +0100, Christoph Moench-Tegeder wrote: > ## Lev Serebryakov (lev@FreeBSD.org): > > > net-p2p/monero-cli shows a lot of exceptions on FreeBSD. Monero's > > github [1] says, that it needs "sysctl -w vm.nr_hugepages=1280" on Linux. > > What is FreeBSD equivalent for this Linux' setting? > > 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. 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.