From nobody Wed Dec 15 15:13:25 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 F011318F18C5; Wed, 15 Dec 2021 15:13:27 +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 4JDdzq56dnz4S1q; Wed, 15 Dec 2021 15:13:27 +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 1BFFDPor003712 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 15 Dec 2021 07:13:26 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1BFFDPKS003711; Wed, 15 Dec 2021 07:13:25 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Wed, 15 Dec 2021 07:13:25 -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: 4JDdzq56dnz4S1q X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Dec 15, 2021 at 10:47:42AM +0100, Kristof Provost wrote: K> > My radical opinion is that per-VNET pcb zones should just be eliminated. K> > The only thing they serve is imposing maxsockets limit separately for K> > each VNET. But we already have the maxsocket limit on the socket zone, K> > which is _global_! K> > K> > Anybody to explain me the sense of the per-VNET per-pcb zone limit K> > set to the same maxsockets value? You can't create a pcb without a K> > socket, which is guaranteed by the in_pcballoc() prototype. Of course K> > I understand that pcbs may outlive the socket. But those pcbs that K> > outlive a socket, are eventually garbage collected as their lifetime K> > is finite. Anyway jail/VNET was never declared as a resource management K> > framework anyway! K> > K> K> rctl(8) does appear to support per-jail resource limits, but I’m not sure how complete or functional that is. The manual doesn't say anything about network resources. The sources of in_pcballoc() neither suggest that any per-something resource management is done that can prevent allocation. -- Gleb Smirnoff