| |||||||||||
Solution in silicon?Solution in silicon?Posted Jul 17, 2003 5:59 UTC (Thu) by proski (subscriber, #104)Parent article: 64GB on 32-bit systems It looks like a deficiency of the x86 architecture (I'm don't know how other architectures do it, I'm just saying it can be done better). While segmentation is separate for different processes, the page mapping is common and cannot be changed without performance impact. If the processor had separate pagetables for the user code and the kernel, the problem would be solved. The problem doesn't seem to be Linux specific. I wonder if any chip maker would consider implementing separate pagetables in silicon. IMHO it should be easier than implementing 64-bit registers or hyperthreading. More conservative approach is known to work well. I think a "64G ready" Xeon would be at least as popular as Itanium.
(Log in to post comments)
Solution in silicon? Posted Jul 17, 2003 19:44 UTC (Thu) by melauer (guest, #2438) [Link] >It looks like a deficiency of the x86 architecture (I'm don't know how>other architectures do it, I'm just saying it can be done better). I'm pretty sure the problem is that 32-bit x86 CPUs can only address 4GB of memory, of which Linux currently allows 1GB to be actual physical memory. The problem isn't x86 per se, but rather the fact that 32-bit x86 CPUs are so powerful and cost-effective nowadays that people want to use them in situations requiring multiple gigabytes of memory and where previously a 64-bit CPU (e.g. SPARC) was used. The funny thing about this whole situation is that 64-bit x86 CPUs are out now (AMD's Opteron). Even if you _must_ have x86, rather than using a SPARC or the like, there is currently an option for doing so without running into this memory limitation. Granted, the Opteron platform needs some time to mature. For example, I seem to recall that there are few (no?) multi-processor Opteron boards out there right now. But I bet that by the time 2.6 comes out (and certainly by the time 2.8/3.0 comes out) this sort of problem will be best solved by using more appropriate hardware, rather than by using software hacks.
Solution in silicon? Posted Jul 18, 2003 1:54 UTC (Fri) by tjc (guest, #137) [Link] I'm pretty sure the problem is that 32-bit x86 CPUs can only address 4GB of memory [snip]IIRC, the P2 (and up) chop 32-bit addressing into 12 bits for a 4K page, 10 bits for the "inner" page table, and 10 bits for the "outer" page table. I don't know the details, though, living further down the food chain as an application programer. :-) I don't follow the kernel lists at all (unless there's a spectacular flame war happening ;-), but has an inverted page table been discussed? Is this possible on a P[234]? That would take a performance hit right off the top, but at least it solves the huge page table problem.
Solution in silicon? Posted Jul 19, 2003 6:34 UTC (Sat) by giraffedata (subscriber, #1954) [Link] There's a more robust solution. No need to make the address translation sensitive to kernel vs user space. Address spaces are just address spaces. The TLB should include an address space ID in its translations. Then you wouldn't purge the TLB just because you switch address spaces. You could switch between user and kernel space and between processes, all with the TLB still warm.
Solution in silicon? Posted Jul 19, 2003 23:25 UTC (Sat) by tjc (guest, #137) [Link] That sounds like a good idea. I can't find much info on it though. My OS book has about two paragraphs on address space identifiers, and googling for "ASID" brings up a page for the American Society of Interior Designers. ;-)
|
|||||||||||