Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Mar 2023 20:30:34 +0000 (UTC)
From:      "Bjoern A. Zeeb" <bz@freebsd.org>
To:        Gleb Smirnoff <glebius@freebsd.org>
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
Message-ID:  <p33n2937-2p2o-3q8r-sq26-1p6qo8o19qr7@serrofq.bet>
In-Reply-To: <Y/gqLrIPQGcuWhTr@FreeBSD.org>
References:  <202302202112.31KLCfQB080359@gitrepo.freebsd.org> <Y/Uz5B6ywWjaa1TB@FreeBSD.org> <CAM5tNy6KFzCarKWze4mjbnqsERUoshHFfZeXzZMF3RurVKf7TA@mail.gmail.com> <Y/cHpcn/1S3Q0Swa@FreeBSD.org> <CAM5tNy6raj72UdmN%2BmFAzWOR%2BzFEV-eMWU6%2BXcSrjKXycu1BBw@mail.gmail.com> <Y/gqLrIPQGcuWhTr@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p33n2937-2p2o-3q8r-sq26-1p6qo8o19qr7>