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
