Tzvetan Mikov (tzvetanmi@yahoo.com) on 5/14/07 wrote:
---------------------------
>You are right, of course, although I don't quite understand why you brought up
>PAE. I was explicitly talking about less than 4 GB RAM. There has been some confusion
>on this because in Linux anything above 1 GB is considered HIGHMEM. This however
>is a design decision specific to Linux and is not necessarily an absolute requirement for a 32-bit x86 OS.
>
>If your applications do not _individually_ require more than 2 GB address space,
>and if your RAM plus your PCI devices is <= 4 GB, why do you really need a 64-bit OS ?
>
>Let's see. Fundamentally, what does the OS kernel need address space for ? Let's assume a 3G:1G user/kernel split.
>
>a) For its own code and data structures, including page tables. 1 GB should be
>more than sufficient for that on a 32-bit system.
>
>b) For memory-mapped hardware. With graphics cards with 512MB RAM and more this
>can be a problem on 32-bit systems. A solution is to map such hardware only in user space.
>
>c) In a system call the OS kernel has to be able access the entire address space
>of the calling process. Obviously this is not a problem, as the kernel can use the user addresses directly.
>
>d) Sometimes the kernel has to access parts of the address space of an arbitrary
>process. Since it needs only parts, not the entire space, it can lock & map the
>necessary address pages to kernel space. Windows does this persistently (the pages
>are mapped in advance). 32-bit Linux ends up doing it dynamically - it maps a page
>if it needs it and it is > 1 GB, and then unmaps it ASAP.
>
>e) For caches. This is the only problematic part. Ideally the kernel should be
>able to use all available RAM as cache, but it can't fit all in the kernel address
>space. However since this is a specialized data structure, it should be possible to map memory in & out as needed.
>
>Am I missing something ?
>
>The point is, the OS doesn't need generic access to all memory at all times.
>So, unless your applications require lots of virtual address space, having 2-3G
>of RAM doesn't necessarily have to be a cause for moving to 64-bit.


It's a long thread, PAE was in there somewhere... ;-)

Anyway, for some OSs, with the limits you listed (<4GB RAM+devices, all small processes), there's no particular pressure to go 64 bit, although that's not universally true.

The one place you run into a problem is with I/O, especially at interrupt time.

Having both the user address space that you're servicing and the real address space accessible at the same time is quite handy for some types of I/O operations. In that case you need more virtual address space than physical. The alternative involves either special casing the driver's environment to always deal with real addresses (extra overhead for many operations), or requiring the driver to know when it needs to use the real or virtual addresses (extra complexity in the driver). In Windows, for example, that’s just part of the basic design of the kernel/driver interface, so in a sense getting to the 4GB limit is “free” because all drivers have had to pay the hidden cost to support it (because of a more complex interface/environment).

There have been OSs where all the address spaces are accessible to the kernel/drivers. Obviously if you do that just with virtual address bits, you'll burn a lot of them, but it does make your life in a driver rather simpler. And having spent a lot of my life in that environment, I think almost anything that simplifies a device driver's existence is a good idea.

Also, there are good reasons to want your virtual address space to be fairly sparse, to make it easier to support things like shared memory. Shared memory in Windows is painful since there's no guarantee that it's mapped to the same place in both processes.