Messages in this thread | | | Subject | Re: using more than 2 GB as a ram disk | Date | Wed, 3 Feb 1999 22:32:10 -0500 (EST) | From | David Wragg <> |
| |
H. Peter Anvin wrote: > 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.
The point is not that this scheme is a good idea, or at all useful, except possibly from a marketing viewpoint. The usual exchange isn't about usefulness:
Person A: Recent Intel x86s can address 64GB transparently to userspace by using segments.
Person B: No they can't, read the manuals.
Given what A probably had in mind, B's response is good enough, so that it has become a knee-jerk reaction for many people. However, pedantically speaking, an OS *could* be implemented for which A's claim is true. Would Albert or anyone else volunteer to write this (based on Linux or any other kernel)? I doubt it. But that doesn't make it impossible.
(As for Albert's bragging rights, I claim precedence: See <URL:http://www.dejanews.com/getdoc.xp?AN=415355834>)
Albert D. Cahalan then wrote: > Usefulness requires a CPU that can handle segment issues quickly. > The Pentium Pro is hopeless, but the Pentium II might be OK enough.
Actually, I think that big as the segment overhead is, it wouldn't be the biggest overhead. Undisguised segmented pointers are sufficient to implement plain ISO C, but if you wanted to port real applications (and libraries, OS kernels, etc) to such a system, it would need to present a flat memory space. There are at least three significant costs to this:
1) Pointer arithmetic. Imagine offsetting a segmented pointer, so that it crosses a segment boundary. Expensive normalisation would be required. By overlapping neighbouring segments by a hefty margin (e.g. 1MB), and lots of cleverness in the compiler, it may be possible to avoid most of the normalizations, but some will remain.
2) Long would have to be 64-bits, to allow pointer->long and long->pointer casts to work as most C programs expect.
3) Most C programs also expect things like:
(T*)((long)pointerToT + sizeof(T)) == pointerToT + 1
So in order to make the pointers cast to long look like a flat 64-bit address space, pointer->long and long->pointer casts have to involve shifting bits around.
These are in addition to the segment load costs. A 2x slow down will probably be a *best-case* scenario for typical C programs.
Dave Wragg
- 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/
| |