Date: Tue, 23 Apr 2002 12:25:31 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: kalts@estpak.ee Cc: "Marc G. Fournier" <scrappy@hub.org>, freebsd-current@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ? Message-ID: <3CC5B52B.49A5A719@mindspring.com> References: <3CC4C683.F9AEF14E@mindspring.com> <20020423092909.N1721-100000@mail1.hub.org> <20020423184534.GA30212@myhakas.estpak.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
Vallo Kallaste wrote: > You can have up to ~12GB of usable swap space, as I've heard. Don't > remember why such arbitrary limit, unfortunately. Information about > such topics is spread over several lists arhives, usually the > subjects are strange, too.. so hard to find out. As I understand it > you are on the track, having 3GB allocated to KVA means 1GB for UVA, > whatever it exactly means. Userspace processes will allocate memory > from UVA space and can grow over 1GB of size if needed by swapping. > You can certainly have more than one over-1GB process going on at > the same time, but swapping will constrain your performance. > I'm sure Terry or some other knowledgeable person will correct me if > it doesn't make sense. Actually, you have a total concurrent virtual address space of 4G. If you assign 3G of that to KVA, then you can never exceed 1G of space for a user process, under any circumstances. This is because a given user process and kernel must be able to exist simultaneously in order to do things like copyin/copyout. > > Is there a reason why this stuff isn't auto-scaled based on RAM as > > it is? > > Probably lack of manpower, to code it up you'll have to understand > every bit of it, but as we currently see, we don't understand it, > probably many others as well :-) A lot of things are autosized. Matt Dillon made some recent changes in this regard. But many things happen based on expected usage. You can't auto-size the KVA because the kernel is relocated at the base of the KVA space. As far as it's concerned, it's loaded at 1M, and as far as processes are concerned, they're loaded in low memory. The main barrier to autosizing things so that expect usage is not an issue is that you have to preallocate page mappings, if not physical pages to back them, at boot time, for anything that can be allocated at interrupt time (e.g. mbufs). The other barrier here is that some things are grouped together that probably out to be seperate: e.g. "maxfiles" controls inpcb, tcpcb, and udpcb allocation, which occurs at boot time, as well as other limits that occur at runtime. So using the sysctl at runtime doesn't adjust everything you think it does, but doing it in /boot/loader.conf does. For the same reason, doing things like setting hash table sizes, and then adjusting things larger doesn't really work out very well, either. It really does boil down to understanding every bit of it... and the lack of resources to help you do that. Bryan Costales is not just "a lazy butt"... there are good, economic reasons that there isn't yet an updated "sendmail" book covering more recent versions of the "sendmail" program. Writing a useful (non-"fluff") technical book, optimistically, takes 2080 hours ... or 40 hours per week for 52 weeks... a man year. By the time you are done, the book is a year out of date, and even if you worked really hard and kept it up to date (e.g. you had 4 authors and spent only 6 months of wall time on the book), the shelf life on the book is still pretty short. The recent "How do I change my KVA size?" question is a good example: a book that came out six months ago would have needed four revisions, based on the changes to the "config" program and the code involved, and would be out of date for 4.5-STABLE, 5.0-RELEASE, and 4.6-RELEASE (when it comes out). At that point, the online version's addenda/errata is so much more useful than the book itself, that there's really no good justification for buying the bok instead of just looking at the online information: it's a totally different set of information. If FreeBSD wants someone to write an in depth book, it's got to have a commitment to not change some basic principles and code for long enough for the book to be useful with something more than just a really old CDROM included in the book itself. -- Terry 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?3CC5B52B.49A5A719>