Skip site navigation (1)Skip section navigation (2)
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-stable" 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>