Re: autotuning kernel vars
Hi Mike, Mike Silbersack wrote on Tue, Feb 05, 2002 at 10:03:14AM +: [..] > Hmph, apologies. I was not aware of the comment in LINT that suggested > setting nmbclusters / nbuf to 0. This comment predates the autoscaling > code, and is wrong. I'll go remove it. Ah, well, thanks. That clarifies it. So for I don't specify any values for NMBCLUSTERS and NBUF, leaving maxusers at 512, and just watch how the machine performs. I just thought about increasing NMBCLUSTERS because somewhere (I don't remember) it was mentioned, that some new code (larger default buffers somewhere in the ip stack?) could make one run out of them. But I guess with maxusers=512 I'm already on the safe side. Thanks, Daniel -- IRCnet: Mr-Spock - kommst du siehst du, gehst du hast du, weisst du, krass! - Daniel Lang * [EMAIL PROTECTED] * +49 89 289 25735 * http://www.leo.org/~dl/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: autotuning kernel vars
On Tue, 5 Feb 2002, Mike Silbersack wrote: > LINT says, and I quote: > > # > # The `maxusers' parameter controls the static sizing of a number of > # internal system tables by a formula defined in subr_param.c. Setting > # maxusers to 0 will cause the system to auto-size based on physical > # memory. > # Hmph, apologies. I was not aware of the comment in LINT that suggested setting nmbclusters / nbuf to 0. This comment predates the autoscaling code, and is wrong. I'll go remove it. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: autotuning kernel vars
On Tue, 5 Feb 2002, Daniel Lang wrote: > Hi, > > (sorry for posting this to two lists, Reply-To: is set.) > > I've just built a new kernel for a just upgraded box to > 4.5-STABLE. I've included > > NMBCLUSTERS=0 and > NBUF=0 > > to try the auto-sizing feature as documented in LINT > > Any advice, even "don't set NMBCLUSTERS to 0", preferred with > "because in your setup happens", but greatly appreciated > in any way. > > TIA, > Daniel LINT says, and I quote: # # The `maxusers' parameter controls the static sizing of a number of # internal system tables by a formula defined in subr_param.c. Setting # maxusers to 0 will cause the system to auto-size based on physical # memory. # Hence, you should set maxusers to 0, not nmbclusters, not nbuf. In fact, for autosizing to work, you should not specify nmbclusters or nbuf whatsoever. The autotuning simply sets maxusers to megs of memory / 2. While this is a huge improvement from having maxusers default to 32 for everyone running GENERIC, it's not some magic feature that will turbocharge your machine. If you have been comfortable with manually setting up your configuration, you do not need to worry about autosizing. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: autotuning kernel vars
* Daniel Lang <[EMAIL PROTECTED]> [020205 13:15]: > I've just built a new kernel for a just upgraded box to > 4.5-STABLE. I've included > > NMBCLUSTERS=0 and > NBUF=0 > > to try the auto-sizing feature as documented in LINT LINT also says if they're unset it will autosize them. > real memory = 1610596352 (1572848K bytes) > Physical memory chunk(s): > 0x1000 - 0x0009efff, 647168 bytes (158 pages) > 0x003a1000 - 0x5fff3fff, 1606758400 bytes (392275 pages) > kmem_suballoc: bad status return of 1. > panic: kmem_suballoc > Now, what I remember it may have to do with some > of the tunings failing. I also have maxusers=512 > (but this caused no problems until now). maxusers will autoscale too - and that works. Maybe there's some kind of conflict between the 3 tweakables that's making the kernal a sad panda? My advice would be to unset all 3 (set maxusers=0 if you insist), and report the bugs in LINT. -- Quigley's Law: Whoever has any authority over you, no matter how small, will atttempt to use it. Rasputin :: Jack of All Trades - Master of Nuns :: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message