Test - Please ignore ----- Original Message ----- From: "David Schultz" <[EMAIL PROTECTED]> To: "Terry Lambert" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, April 22, 2002 6:09 AM Subject: Re: FreeBSD 4.5-STABLE not easily scalable to large servers ... ?
> Thus spake Terry Lambert <[EMAIL PROTECTED]>: > > If you want more, then you need to use a 64 bit processor (or use a > > processor that supports bank selection, and hack up FreeBSD to do > > bank swapping on 2G at a time, just like Linux has been hacked up, > > and expect that it won't be very useful). > > I'm guessing that this just means looking at more than 4 GB of memory > by working with 2 GB frames at a time. As I recall, David Greenman > said that this hack would essentially require a rewrite of the VM > system. Does this just boil down to using 36 bit physical addresses? > Are there plans for FreeBSD to support it, or is everyone just waiting > until 64 bit processors become more common? > > > You can't > > really avoid that, for the most part, since there's a shared TLB > > cache that you really don't have opportunity to manage, other than > > by seperating 4M vs. 4K pages (and 2M, etc., for the Pentium Pro, > > though variable page granularity is not supported in FreeBSD, since > > it's not common to most hardware people actually have). > > Does FreeBSD use 4M pages exclusively for kernel memory, as in > Solaris, or is there a more complicated scheme? > > > If you increase the KVA, then you will decrease the UVA available to > > user processes. The total of the two can not exceed 4G. > > In Linux, all of physical memory is mapped into the kernel's virtual > address space, and hence, until recently Linux was limited to ~3 GB of > physical memory. FreeBSD, as I understand, doesn't do that. So is > the cause of this limitation that the top half of the kernel has to > share a virtual address space with user processes? > > I'll have to read those books one of these days when I have time(6). > Thanks for the info. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
