From nobody Sun Mar 05 20:30:34 2023 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 4PVCyR537gz3twKs; Sun, 5 Mar 2023 20:30:39 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PVCyR4bQrz3wLm; Sun, 5 Mar 2023 20:30:39 +0000 (UTC) (envelope-from bz@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1678048239; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=thQJWLpmN5IDQB40udHLQk/itCwZzhaI4+UuLKizfuk=; b=dzXuyXMOkE440M+j04Tayq0JjIWM4ufmWlzrk1BrvKU7Y6zFFyLZPqX0wbjL9MyUcvge+0 EXsaLKnjXksp4ycqtqy5sUlyWfegjRtX9tmxkZviommOc1xF6NhmsdUgBa6jCJ4yK4EvbG ODqRxEwwxSuokCN8Bz4yJ/SMukgWD8vLxKj+6n9CeLKMgqLzN/wgUVHHMzRx4IpGy5VAMK S5cv4vPhM6St/jJX4B8m3hGT/aJ/8lVoXqDN4CY2mkU+16/WzyJ/f8+YwRaiHfJ4l0hVnE Kmw8F4gYrd1aYzPZHuA9WOwg1NwR74794/w2BjHzQBE90iiA56Ysv/eh0gExyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1678048239; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=thQJWLpmN5IDQB40udHLQk/itCwZzhaI4+UuLKizfuk=; b=Icap3B4BcEcfYVOxGaxzoZs+Xr3kKCfMUUVvriEN6CrjFzROh8XjTVaOZSgggkNpbjXxZZ Bcfj86T5hL7Y/lv3ETAYSVNuhtB88muubpS9YQ66E7KPT3g/zEXUxZggN5Y+fU8HQ8GHsi +xHRBG/njhtKYjfXkd8BzexiquAYu/wt5GJPjqEZwX3kdFXSw7BEbN1pJIqg4vEf80xIaw HykgYKI0L1JfIrun5LxgYDRSVXQUEBA8bzWFmlqynqdfu0Dehy8XqCOmgZVH/Ggwpdl0r+ YaTFg7qlbqai0/Kkx8CWIbhX8Nx7j8JWjTgpoAvwLeqLEmnrOe8BN1Ge9DNNeg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1678048239; a=rsa-sha256; cv=none; b=R9DDC8AkwtPrjCCRSjAQAyq4Q6gOU/dW9D9zGLzRbrJvK/mQovFVQRQyiwN/r8l2zg3JDn hNqTBZHdLNU0N7r23sBYvHGdSXrCbwxSe8NOBdHhaImxHhYrFnAd1qqZ9J3yg4buSc8jCO pyPwOqrVOmrjVuSswLuF938XYSFFo6PAiq2Wnv4s4u+T6ppCs/oyL+CwlipSKiJvnUvqy8 TL7hb4LmUj2aQno+LIffkvPQGDoZzjoiat5yPBtXKPrrwz38RNcVFcpH+OMzwQuWWGuemX G3JEc1YBR788r91QGo0dnuDIbsg6CZfUXZK0hZTaMYHZKp5eS29Rc4RggXUetg== 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 Root Certificate Authority" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4PVCyR2Sm6zkyn; Sun, 5 Mar 2023 20:30:39 +0000 (UTC) (envelope-from bz@freebsd.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 24DFC8D4A179; Sun, 5 Mar 2023 20:30:38 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B75285C3A831; Sun, 5 Mar 2023 20:30:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id k5LxYZYJZukE; Sun, 5 Mar 2023 20:30:36 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (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) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 88DF05C3A82F; Sun, 5 Mar 2023 20:30:35 +0000 (UTC) Date: Sun, 5 Mar 2023 20:30:34 +0000 (UTC) From: "Bjoern A. Zeeb" To: Gleb Smirnoff cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: ef6fcc5e2b07 - main - nfsd: Add VNET_SYSUNINIT() macros for vnet cleanup In-Reply-To: Message-ID: References: <202302202112.31KLCfQB080359@gitrepo.freebsd.org> 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: text/plain; charset=US-ASCII; format=flowed X-ThisMailContainsUnwantedMimeParts: N On Thu, 23 Feb 2023, Gleb Smirnoff wrote: > Rick, > > On Thu, Feb 23, 2023 at 05:56:06AM -0800, Rick Macklem wrote: > R> > This one actually doesn't look correct to me. What happens here is that the sysctls > R> > will affect only the default VNET. > R> > > R> Yes, but the sysctls are mostly useless anyhow. I don't know how to make them > R> work in a prison. (I know how to use SYSCTL_FLAG_VNET, but that does not > R> work in this case.) > > Doesn't they work as intended in my patch D38742? > > R> > I think the VNET-itezation of this file went a bit wrong. You don't need to convert > R> > static structures to malloced when you VNET-ize a module. The infrastructure should > R> > take care of memory management. > R> > > R> Not if you want to keep the vnet footprint small. This was necessary > R> so that nfsd.ko > R> (and friends) will load dynamically. Without the conversion to > R> mallocs, it would complain > R> the vnet was out of memory when nfsd.ko tried to load. > R> (I'm sure I didn't need to do all of them, but it made sense to keep > R> the vnet footprint > R> as small as possible.) > R> > The dynamic sysctl context seems to be unneeded from the very beginning. It was > R> > always attached to the static softc. Suggested patch: > R> > > R> > https://reviews.freebsd.org/D38742 > R> > > R> I'll look at it, but if it stops malloc'ng softc, then I will be > R> worried w.r.t. vnet footprint and > R> dynamic loading. (Note that the structure has an array of hash list > R> pointers in it, so it > R> is rather large. > > Replying to you and Bjoern's email too here. Well, if we want a fully blown > virtualized network stack, and this is what VIMAGE is, then, well, we need a > full chunk of memory to keep a network stack data. So, if there is a limit > there, (Bjoern mentioned 8k) then this limit needs to be increased as more > and more subsystems are virtualized. I also don't see how we actually save > any memory using malloc(9) instead of using memory provided by VIMAGE? The > kmem use would be roughly the same if not worse. What exactly are we saving > here? You save sapce in the vnet module area (1 pointer instead of n KB of data). It is only the vnet module area which is contraint given it's special memory location calculation, duplication, and update for each vnet. The overall memory is not reduced. See the comment in sys/net/vnet.c which describes the reason and how it works quite well. /bz -- Bjoern A. Zeeb r15:7