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-current" in the body of the message

Reply via email to