Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: using more than 2 GB as a ram disk | Date | Wed, 3 Feb 1999 22:32:10 -0500 (EST) |
| |
>> The Alpha only has about 43 address bits; is the Alpha not 64-bit? > > The Alpha can be extended to 64 bits **WITHOUT SOFTWARE IMPACT**.
Note that you can still use the 4 kB pages to get better resolution. I left them out of the original plan only because they seem to make most people misinterpret the system.
Pages subdivide the larger chunks. There are 2048 real pages in an 8 MB segment, but those need not be the numbers. You could instead use 8 kB "pages", each composed of 2 hardware pages. (Linus once mentioned this -- I'm not crazy here at least) Assuming you only need a 35-bit address space, you get 512 "pages" in a 4 MB segment. If you prefer, have 64 kB pages and 16 MB segments. Whatever you like.
Terms I will use:
page = small unit, typically 4 kB to 64 kB size (a logical page) Each page is a constant number of hardware pages.
chunk = large unit, typically 2 MB to 8 MB size Each chunk is represented by a segment.
(in the simple version, those were the same huge size)
Pages are not completely independent of chunks. Chunks let us bypass the 32-bit virtual address space, while pages make mmap() better, reduce page fault time, and reduce memory waste.
Processes can take both page faults and chunk faults. Consider:
A. The chunk is mapped (a valid segment) but the page (hardware pages) is (are) not present. This is a simple page fault.
B. The chunk is not mapped, but the page is present. That is, the system still has a disconnected page table tree and some pages that would be mapped if that tree were assigned to a segment register. This is a chunk fault.
C. The chunk is not mapped and the page is not present. This is a combination fault. (both page fault and chunk fault)
It should be obvious that the chunk size used by the OS does not directly influence the page size as seen by userspace. There is this relationship: hardware page <= logical page <= chunk
Compatibility with BSD NFS servers would suggest an 8 kB logical page.
>>> you either store pointers in a non-flat format or normalize >>> them every time; >> >> Yes, exactly. For userspace, this is hidden by the compiler. >> >>> once (or if) Intel adds more adds more address bits than 36 >>> you're hosed again. >> >> At that point I expect a fix for the virtual address space too. >> If not, you can extend the hack a bit. Don't use Electric Fence. > > ... and your old binaries are worthless.
No, they work fine. Old binaries can not run with a large page size, but that is not a serious problem.
> These kinds of proposals have been around for a long time (I remember > seeing them back in the i386 days, using external logic.) They're > just as useless now as then.
Usefulness requires a CPU that can handle segment issues quickly. The Pentium Pro is hopeless, but the Pentium II might be OK enough.
Even if performance is horrid, this hack could have some value. Marketing will love it :-) and I could reproduce 64-bit problems on a normal PC. The hack looks fun too.
- 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/
| |