Date: Sun, 16 Mar 2003 16:14:36 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Mark Tinguely <tinguely@casselton.net> Cc: andykinney@advantagecom.net, freebsd-hackers@FreeBSD.ORG Subject: Re: increasing KVA_PAGES and broken pthreads Message-ID: <3E75136C.54F3A98@mindspring.com> References: <200303151448.h2FEm4Mt089695@casselton.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Tinguely wrote: > Intel x86 hardware allows windows of 4GB of virtual memory even if > you have the PSE-36 and the PAE extensions with more the 4GB of > physical memory. Sound a little like Intel's 64KB windows, but > if I remember correctly, the 4GB does not have to be contiguous. > > It would require a true MMU such as those in the 64 bit architectures > (AMD opteron, Intel ia64, sparc64) to simulataneously be able to use > more than 4GB of RAM. > > So far the thought it is better to go with a true 64 MMU than take > and get a flat address space than take the performance hit (, plus > the memory loss for the much larger page table without much benefit) > than try to shuffle in the 4GB windows. Check the thread on this topic > in the archives. Jake Burkholder is doin PAE work in the context of FreeBSD. IMO, it should be committed in "pae386" instead of "i386" (e.g. treated like "pc98"). I don't know if this is possible, unless the hardware/software VM handling partition is sufficiently opaque (it should be, but there may be some border cases). Other than that, everything you've said is true, I think. I would add that that still leaves you with 4G of space to split between KVA and UVA, so it will not solve Mr. Kinney's problem in the least, since his problem is available kernel address space, not actual physical RAM. The KVA space *could* be split from the UVA space, giving 4G each, rather than 4G total. But for this to happen, you would have to decouple the kernel from dealing with process data that is passed to it from UVA by simply establishing page mappings for it, rather than copying it around. If you did that, it would, I think, drastically increase the amount of copying that happens on reads, writes, etc., and vastly slow down the copyin, copyout, uiomove, and similar functions, as well as making mmap of physical device memory, such as the AGP aperture used by X11 for AGP-enhanced video cards, rather harder to implement (if you consider that to access particular memory from user space may require moving elelments of your 4G window around, in the trap handler for page faults, you will see the problem). Practically, PAE/PSE-36 are not really useful, in that they do not keep you from bumping your head in the kernel or in user space processes, when it comes to available address space, which is *much* more important that the amount of available physical memory. And you can get 4G for each (per the above), without going to PAE/PSE-36. Short version: no matter what you do on a 32 bit architecture, a "char *" is going to be 32 bits. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E75136C.54F3A98>