> > BT> I've also heard about Intel's large addressing extensions (keep 2GB > > BT> in normal address space, page around the top 2 GB, you get 64 GB
The extension referred to above concerns the 4 gig limit inherent in a 32 bit address space with byte addressable memory. The 4 gig limit is on the amount of physical memory that the CPU can directly address. The virtual address space on x86 also happens to be 32 bits in size. Historically on many x86 unixlike oses the upper half of the virtual address space (basically any memory address whose most significant bit was 1) was used by the operating system and was not acessible to application code. This meant that a single process could only usefully address 2 gigabytes of virtual memory at a time. For some time now it has been possible to build linux kernels where the amount of virtual memory available to the apps is 3 gigabytes, with the kernel making do with 1 gig of virtual memory. This was purely a software change. The CPU page addressing extensions allows the cpu to use more than 4 gigs of physical memory. However there is no way around the virtual memory address size limit, so not even the operating system can address it all simultaneously. However it can allocate all of that memory to different proceses, so if you have a single process that needs to access 30 gigs of memory you'll want a 64 bit machine, but if you have 12 processes that each need 2.5 gigs of RAM you're all set. > > eww, that sounds like manual management of extended memory. like the > > days of overlays or even pdp-11 extended memory (which i used to access > > 22 bit address (yes, 22 bit PHYSICAL space) from a 16 bit cpu.). not Fortunately only the operating system has to deal with the addressing hacks required. > Personally I think it would be great to have a system call to say, > "Page this in, because I'll want to be there soon." The > multi-process solution is the next best thing. It is called madvise(). -- Jason _______________________________________________ Boston-pm mailing list [EMAIL PROTECTED] http://mail.pm.org/mailman/listinfo/boston-pm
