From nobody Wed Dec 29 01:03:55 2021 X-Original-To: dev-commits-src-all@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 74892190D24A; Wed, 29 Dec 2021 01:04:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JNtTN257Qz4tqY; Wed, 29 Dec 2021 01:04:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 648688D4A215; Wed, 29 Dec 2021 01:04:00 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0EC80E707FC; Wed, 29 Dec 2021 01:03:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 98MiqxBLIDVp; Wed, 29 Dec 2021 01:03:57 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BEAC6E707E8; Wed, 29 Dec 2021 01:03:56 +0000 (UTC) Date: Wed, 29 Dec 2021 01:03:55 +0000 (UTC) From: "Bjoern A. Zeeb" To: Marko Zec cc: Gleb Smirnoff , Kristof Provost , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: eb93b99d6986 - main - in_pcb: delay crfree() down into UMA dtor In-Reply-To: <20211229002947.7b7d5e94@x23> Message-ID: References: <202112051847.1B5Il2GP030287@gitrepo.freebsd.org> <28AE53F1-2B22-444B-B1EC-1600FA741FE2@FreeBSD.org> <20211229002947.7b7d5e94@x23> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-570370836-1640739836=:68830" X-Rspamd-Queue-Id: 4JNtTN257Qz4tqY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-570370836-1640739836=:68830 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 29 Dec 2021, Marko Zec wrote: > On Mon, 27 Dec 2021 16:46:54 -0800 > Gleb Smirnoff wrote: > >> On Fri, Dec 17, 2021 at 10:17:55PM -0800, Gleb Smirnoff wrote: >> T> T> K> The jails created by that test never go away. It’s as if >> T> T> K> `crfree(inp->inp_cred);` doesn’t actually get called. And >> T> T> K> indeed, it looks like inpcb_dtor() does not get called at >> T> T> K> all. >> T> T> >> T> T> Yes, I faced this problem today, too. :( >> T> T> >> T> T> My radical opinion is that per-VNET pcb zones should just be >> T> T> eliminated. The only thing they serve is imposing maxsockets >> T> T> limit separately for each VNET. But we already have the >> T> T> maxsocket limit on the socket zone, which is _global_! >> T> T> >> T> T> Anybody to explain me the sense of the per-VNET per-pcb zone >> T> T> limit set to the same maxsockets value? You can't create a pcb >> T> T> without a socket, which is guaranteed by the in_pcballoc() >> T> T> prototype. Of course I understand that pcbs may outlive the >> T> T> socket. But those pcbs that outlive a socket, are eventually >> T> T> garbage collected as their lifetime is finite. Anyway jail/VNET >> T> T> was never declared as a resource management framework anyway! >> T> T> >> T> T> So, for this particular problem I would suggest just eliminate >> T> T> per-VNET pcb zones, but in general the fact that idle SMR zone >> T> T> may never purge its cache sucks and needs improvement. >> T> >> T> I have created a patch that would mitigate that problem. Once the >> T> zones are global, the jails will eventually die if there is some >> T> pcb zone traffic. >> T> >> T> https://reviews.freebsd.org/D33542 >> >> Despite I still believe that PCB zones belong to global state rather >> than to a VNET, the patch doesn't help to mitigate massive memory >> leaks with vnet jails on a machine that is dedicated solely to run a >> test suite. If machine does nothing except a test suite, there is >> almost zero pcb traffic. If there is no pcb zone traffic, the SMR >> caches stay, and thus destroyed jails will also stay. Our vnet jail >> "weights" a lot! Even with the global PCB zone patch applied, each >> vnet jail creates 33 UMA zones! >> >> I think we need a KPI to purge the SMR caches, and we also need to put >> vnet jails on a diet. These are two independent problems, of course. > > +1 for nuking all per-vnet PCB zones and the alike! At the time I > V_irtualized them during the early stages of VNET implementaion, the > focus was on correctnes and tracking of inter-vnet resource leaks. Once > that step was reasonably completed (circa 15 years ago!), per-VNET > zones became a pure waste of memory, amplified with per-CPU local free > pools for each zone, not to mention the PITA with VNET cleanups... Please remeber that we do have limits on some zones and if you de-virtualise them those limits become global and that quickly will be a problem. -- Bjoern A. Zeeb r15:7 --0-570370836-1640739836=:68830--