Date: Thu, 06 Dec 2001 06:23:31 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Leo Bicknell <bicknell@ufp.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Can TCP changes be put in RELENG_4? Message-ID: <3C0F7F63.90B753F3@mindspring.com> References: <20011205085750.I28101-100000@coredump.scriptkiddie.org> <200112052142.fB5LgVM53167@apollo.backplane.com> <3C0EF953.54CF24DB@mindspring.com> <3C0F0803.7010506@viasoft.com.cn> <3C0F0D02.8AEA9E48@mindspring.com> <20011206081059.A58740@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I've shortened the Cc: list (don't know if you are on -hacker, Leo, so I left you on; sortry if you get two copies). Leo Bicknell wrote: > > The problem with doing this is that it sort of grates against the > > idea of a "GENERIC" entirely. > > The problem with GENERIC is it is the lowest common denominator. > While it's really cool we can still boot on a 386 with 4 meg of > RAM, making the compromises to make that happen is not terribly > useful. No. GENERIC can not auto-size its structures at runtime. This means even something as relatively simple as scaling of amount of real, physical RAM, is not an option. After that hurdle is passed, then installation specific tuning of some subsystems at the expense of others (e.g. never drop below a low watermark for certain structures, but permit allocation of RAM to mbufs on a network server or process memory on an application server, etc.) needs to be considered. This can't be done now, since once respources are committed to a specif purpose, they must remain committed to that purpose. I think that it's also going to far to adjust the KVA space at boot time, instead of runtime, though that should certainly become feasible at some point (just not now). One could easily imagine a KVA space of 3G for a network cache server, but 1G (or less) for an application server, and such a beast would be impossible to get in a runtime adjustment scenario. > GENERIC should be tuned _above_ the median PC, because after it's > out PC's will continue to be upgraded. If we want to retain the > (easy) ability to boot on a 4 meg machine we can supply a second > MICRO-GENERIC. This implies the issue of distributing multiple kernels, and the sysinstall issues that that causes, have all been resolved. At a bare minimum, installation requires a minimal resource kernel for boot, since boot could be taking place on a minimally resourced machine. > For some random thoughts, MAXMEM should be 256M minimum, 1G > preferably. This is an operational limit. It's possible to compile a kernel with a large value, and dynamically size it down to reasonableness, based on knowing the real physical memory size. This is a special case, however, since what we are really talking about with MAXMEM is an administrative limit bounded by swap and user memory size. > MAXUSERS should be perhaps 128 or 256 out of the box. This is much less cut and dried, since these things are (probably incorrectly) used to size other allocations (allocations which also could be reasonably dynamically sized, in the absence of intentional administrative override, e.g. in the local loader.rc). > I'd suggest our target should be a P-III 600 with around 256M of > RAM as what Generic should be tuned for.... Can't. The static allocations for that much assumed RAM would result in the machine not booting, with the amount of RAM for the page tables alone ~1/4M. By default, the 120M KVA space mappings are arguably overlarge for small memory machines. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C0F7F63.90B753F3>