Date: Tue, 24 Apr 2001 20:38:33 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: current@freebsd.org Cc: terry@lambert.org Subject: Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable Message-ID: <200104242038.NAA21190@usr07.primenet.com>
next in thread | raw e-mail | index | archive | help
] This looks good except that ncallout is still based on MAXFILES,
] without this being fixed I think people might get bitten by
] raising the tuneable too high then being unable to allocate
] enough callouts. Can you take a look at this and make sure there's
] nothing else using MAXFILES like that?
Everywhere else uses the value of the variable, rather than
the value of the MAXFILES manifest constant; this is true for
4.3-release, if not for -current, so -current should be checked
too, I suppose, but I can't see someone intentionally adding
another dependency.
I actually also have a question for you: what bad things really
happen if ncallout is (relatively) much smaller than maxfiles?
As far as I can tell, it doesn't cause real problems...
The "ncallout" value should technically be a power of 2; I think
the code in the various machdep.c is probably broken, and that
the valloc() ought to use "callwheelsize" instead of "ncallout",
so that "callwheelbits" is not inaccurate, nor is "callwheelmask".
In any case, I really can't see how to easily do this at runtime,
short of stuffing a SYSINIT(SI_SUB_TUNABLES, SI_ORDER_ANY) into
param.c; that really won't work, since the machdep.c code is
executed very early on in the boot cycle.
It seems that it needs to have a more direct reference to a:
TUNABLE_INT_FETCH("kern.ncallout", 0, ncallout);
Early on in cpu_startup().
I guess if you want to get technical, the fact that the sockets
and so on are allocated based on the value of maxfiles, and set
themselves based on a maximum value of both means that the
sockets stuff should be ripped out as a tunable entirely, and
left to rely only on maxfiles (not MAXFILES).
I guess that should you also want to get technical, the sysctl
for kern.maxfiles should really be read-only after boot, and
not read-write, since the socket structures have already been
(incorrectly) sized by the time you have a chance to adjust the
number in user space.
FWIW: ncallout is actually a larger can of worms than I wanted
to open, which is why I didn't just make it its own tunable...
would that be an acceptable compromise?
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104242038.NAA21190>