From owner-freebsd-current Tue Apr 24 13:37:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id D06AE37B422 for ; Tue, 24 Apr 2001 13:37:51 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id NAA22358; Tue, 24 Apr 2001 13:37:50 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp05.primenet.com, id smtpdAAA.OaGER; Tue Apr 24 13:37:30 2001 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id NAA21190; Tue, 24 Apr 2001 13:38:33 -0700 (MST) From: Terry Lambert Message-Id: <200104242038.NAA21190@usr07.primenet.com> Subject: Re: PATCH to make maxfiles, maxfiles per proc boot-time tunable To: current@freebsd.org Date: Tue, 24 Apr 2001 20:38:33 +0000 (GMT) Cc: terry@lambert.org X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ] 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