> The biggest problem IMO is not the vm structures overflowing, but the fact that > _all_ the physical memory is mapped into a portion of the virtual space of each > team (in the kernel part, which is limited to 2G). Exactly. Here are a few problems you might have (and I probably forgot some) : -somewhere around 1GB, mapping physical RAM into kernel space starts to be an issue. The code that assumes that physical RAM is always mapped must be re-written, including (but not limited to) the vm code that handles page tables, which must now map the page directories and access them through virtual addresses (which involves making that code somewhat re-entrant) -beyond 2GB, some 32-bit values may overflow. You need to make sure that you use unsigned data at all times. -somewhere around 3.5GB, some of the physical RAM starts to be hidden from 32-bit PCI devices. This limit is similar to the 16-MB limit of ISA. -somewhere around the same 3.5GB, you need to enable 36-bit physical addressing (PAE), and a bunch of internal vm structures and vm code may have to be re-written to handle the extra bits. -we might see a point where IA32 desktop machines can eat 64GB of RAM, but I am not sure that it will ever become an issue for Joe Average Consumer (IA32 might disappear before we reach that point). And I would assume that intel would simply add a few address pins to their CPUs (and the matching bits in the page directories) if it ever became an issue. Also, the following problems can appear (and I probably forgot some) : -somewhere between 512MB and 2GB (depending on the application), the 2GB part of the address space that is reserved for user-space starts to be a bit too small. Efforts must be made to shrink kernel-space to something much smaller. 256MB sounds like a "reasonable" target. This means that kernel-space must be able to allocate memory directly in physical space and map it on-demand (vm structures, page directories, disk cache, loader cache...). -(unrelated to the previous one). Even with a 2GB kernel space, and even without mapping physical memory in it, kernel space can start to become small. Storing 2GB of data in the disk cache might not be that unreasonable. Also, the vm structures and the page directories can start to consume more and more address space, to a point that might become critical. The solution is the same one as the one in the previous point. -Even with a reduced kernel space, you'll eventually reach a point where a 4GB address space is too small for user-space. You need to allow user-space to allocate memory in physical space and to map it on demand. -- Jean-Baptiste Queru <jb@xxxxxxxxx>