>>> Call it ridiculous. i386 et al only has 32 bits of linear address
>>> space. It can't work.
>>
>> However the PPro, PII, (PIII?) has 36 bit address; if I remeber correctly.
>> That should give plenty of additional memory space.
>
> *PHYSICAL* address space, yes. It is not accessible to a process.
>
> Please people, learn about address spaces before commenting on this ad
> nauseam.
Before I write anything else: I am aware of the 32-bit virtual
address space.
Processes can have more than one segment, and 32-bit virtual address
spaces can themselves be made virtual. I suppose one could say that
the following hack uses segments to implement paging of a 36-bit
virtual address space.
Let's assume that we tile memory in 8 MB chunks rather than the
normal 4 kB chunks. (23 bits of address space already) Each process
gets access to nearly 8192 chunks of memory, one per segment.
This gives nearly 36 bits worth of user address space, of which 31 bits
worth may be accessed without a segment fault.
About that 32-bit virtual address space:
Assuming a 2 GB split, there are 256 chunks available in the
virtual address space. That is, only 256 segments may be valid
at once. An attempt to access any other segment will cause a
fault, upon which the kernel must:
1. pick an 8 MB victim area
2. mark the victim segment inaccessable
3. disconnect page tables used by the victim segment
4. connect page tables for the area that just faulted
5. make the faulting segment point to the chosen area
6. let the faulting segment be accessable
The compiler must be hacked to use a 64-bit model, with pointers
normallized. The low 32 bits of a pointer would only hold 23 bits
of the address space; the other 13 bits are the segment. This hack
was fairly common for DOS software, not something I dreamed up.
Yeah, this is slow. Every memory access needs a segment override.
The job gets done though: true flat-memory 64-bit software on ia32.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/