From nobody Tue Dec 28 00:46:54 2021 X-Original-To: dev-commits-src-main@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 86B0E191A68D; Tue, 28 Dec 2021 00:46:58 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JNG802nPrz3L6x; Tue, 28 Dec 2021 00:46:56 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1BS0kslr006160 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 27 Dec 2021 16:46:54 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BS0ksAb006159; Mon, 27 Dec 2021 16:46:54 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Mon, 27 Dec 2021 16:46:54 -0800 From: Gleb Smirnoff To: Kristof Provost Cc: 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 Message-ID: References: <202112051847.1B5Il2GP030287@gitrepo.freebsd.org> <28AE53F1-2B22-444B-B1EC-1600FA741FE2@FreeBSD.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 4JNG802nPrz3L6x X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 162.251.186.162 is neither permitted nor denied by domain of glebius@freebsd.org) smtp.mailfrom=glebius@freebsd.org X-Spamd-Result: default: False [-1.78 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[glebius]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; DMARC_NA(0.00)[freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_HAM_LONG(-0.60)[-0.595]; NEURAL_HAM_MEDIUM(-0.19)[-0.188]; NEURAL_HAM_SHORT(-0.89)[-0.892]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:27348, ipnet:162.251.186.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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 indeed, it T> T> K> looks like inpcb_dtor() does not get called at 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 eliminated. T> T> The only thing they serve is imposing maxsockets limit separately for T> T> each VNET. But we already have the maxsocket limit on the socket zone, T> T> which is _global_! T> T> T> T> Anybody to explain me the sense of the per-VNET per-pcb zone limit T> T> set to the same maxsockets value? You can't create a pcb without a T> T> socket, which is guaranteed by the in_pcballoc() prototype. Of course T> T> I understand that pcbs may outlive the socket. But those pcbs that T> T> outlive a socket, are eventually garbage collected as their lifetime T> T> is finite. Anyway jail/VNET was never declared as a resource management T> T> framework anyway! T> T> T> T> So, for this particular problem I would suggest just eliminate per-VNET T> T> pcb zones, but in general the fact that idle SMR zone may never purge T> T> its cache sucks and needs improvement. T> T> I have created a patch that would mitigate that problem. Once the zones T> are global, the jails will eventually die if there is some pcb zone T> 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. -- Gleb Smirnoff