Linux handles the machine independent/dependent layer in a unique way, making page table management a bit tricky. Mel Gorman gives you the skinny on the process in this sample chapter.
Linux Page Table Management
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
And here is the documentation of the Linux 2.4 VM;
http://www.csn.ul.ie/~mel/projects/vm/
Another _great_ VM system;
http://ccrc.wustl.edu/pub/chuck/tech/uvm/
Linux handles the machine independent/dependent layer in a unique way, making page table management a bit tricky.
Not exactly the very best way to promote a technology… it doesn’t sound especially easy to maintain…
Interesting read.
I’d be interested to know how Linux treats not-present PTEs on an x86 system. When they’re not-present the majority of bits in the entries are available for programmer use. I didn’t see it mentioned in the article (Although I might have missed it). The obvious thing is to use those bits for the virtual memory implementation, so I wonder if that’s what the Linux folks do. More questions to answer, but I’m not gonna buy the book to find out. Guess I should read the code sometime.
Considering the Linux is possibly the most portable kernel on the planet (definitely the most portable general purpose OS kernel), including machines without memory management units, I’d say it is a fairly good technology.
RE: Err (IP: —.range81-152.btcentralplus.com)
Linux puts a “swap entry” into dirtied anonymous ptes after it swaps the page out and the entry becomes not present (on all architectures, not just x86).
>Considering the Linux is possibly the most portable kernel on
>the planet (definitely the most portable general purpose OS
>kernel), including machines without memory management units,
>I’d say it is a fairly good technology.
Well, yes. But it doesn’t generalize very much over the arch
dependant layer. Linux enforces a 3 level page directory/lookup, which is used on x86(and some other) but not
on everything, making alot of quirks for those implementation.
The pmap approach in the *BSDs is way cleaner imho on this matter.
But is there a difference in efficency?
I don’t know much about pmap vs Linux’s 3 level page, I’m just asking..
> But is there a difference in efficency?
>
> I don’t know much about pmap vs Linux’s 3 level page, I’m just asking..
API based page translation may or may not be more efficient. On x86, pmap would still break down to page tables, pmap just provides an abstracted API.
On architectures like SPARC V9 and MIPS, which have no page tables but simply a TLB instead, pmap may simply be thin wrappers to the TLB update routines, or may cache a large number of translations behind the scenes, again in the form of a page table, perhaps.
Architectures like PowerPC use inverted page tables, which doesn’t really fit in with Linux’s forward page table abstraction very well. Again, pmap can handle this cleanly with an API which hides this information.
The upshot is that it is neither more nor less efficent by definition. It depends on the implementation.
But pmap is certainly more flexible, allowing redundant information to be dumped when not needed. To be frank, Linux MM sucks rocks, and the three level model has already been broken by x86-64, which uses a four level page table. Pmap would not have had any problems (just write a new pmap layer.)
So pmap can be more space efficient, and is easier to maintain.