Date: Mon, 22 Apr 2002 03:24:01 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jeroen Ruigrok/asmodai <asmodai@wxs.nl> 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: <3CC3E4C1.6A9893E8@mindspring.com> References: <20020420190408.O30724-100000@mail1.hub.org> <20020422060449.GE54143@daemon.ninth-circle.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeroen Ruigrok/asmodai wrote: > Take a look at this: > http://www.freebsd.org/cgi/getmsg.cgi?fetch=245329+248644+/usr/local/www/db/text/2001/freebsd-hackers/20010624.freebsd-hackers This is actually no longer valid, since there have been changes to both the PDE caclcualtions and the kernel base definition to try and make it "more automatic" the change the KVA space size. At the time of the referenced posting, the modifications necessary were to /sys/conf/ldscript.i386 and /sys/i386/include/pmap.h. David also neglected to document how he calculated the "511", which is actually "511 for a UP system, 510 for an SMP system", which is to divide the kernbase by 0x00400000, after subtracting 0x00100000, and then subtracting the recursive entry out of the total. You also have to subtract out the private entries (if any) for SMP, etc.. Basically, you have to calculate the number of descriptor entries required to map the entire KVA space as 4K pages from 1K of 4K page tables (1K worth of entries in a 4K page descriptor table for the address space). Of course, now everyone is going to say "how do I... how do I...", wanting one of the six ways you have to do it, based on the FreeBSD version and/or intermediate release (-release? -stable? -security? -some-date-here?), rather than figuring out the answer based on a single known release. The other issue here is that the number 1 reason for wanting to dick around with this is to be able to add more physical memory, and to do that successfully, you have to know a hell of a lot more about tuning FreeBSD than reading the happy-fun "tuning" manual page can ever teach you, without you understanding how the OS actually does its thing at a low level. I personally consider the "tuning" man page as just a knee-jerk reaction to bad publicity resulting from naieve benckmarking. IMO, it's much better to just give elliptical clues, and then leave the job to the people who can follow the clues and learn enough that they not only get the right answer, but then end up knowing enough about *why* it's the right answer to be able to do the other required tuning. If FreeBSD would ever sit still long enough for someone to get a book out, there's probably be a book on the subject (Kirk has been working on one for a year now, according to several people, called "The Design and Implementation of the FreeBSD Operating System"; no, I don't know what version it's supposed to apply to); IMO, an architect should set some things in stone, and leave them there long enough that documentation doesn't immediately go out of date. It's a hazard of Open Source projects, in general, that there are so many people hacking on whatever they think is cool that nothing ever really gets built to a long term design plan that's stable enough that a book stands a chance of having a 1 year lifetime. Basically, it'll boil down to paying someone who "knows where the bodies are buried" to do the work for you, if you want to get more than just a hack job. 8-(. -- 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?3CC3E4C1.6A9893E8>