Linux Kernel Memory Management Paging Levels

6
votes

I'm reading through the book "Understanding Linux Kernel" by Bovet and Cesati. In the second chapter, under "Paging in Linux" the author mentions how Page Middle and Upper Directories are eliminated with 32 architectures not having PAE enabled. I'm having trouble following what the author means.

They have been loose in their treatment and does not make a whole lot of intuitive sense.

For 32-bit architectures with no Physical Address Extension, two paging levels are sufficient. Linux essentially eliminates the Page Upper Directory and the Page Middle Directory fields by saying that they contain zero bits. However, the positions of the Page Upper Directory and the Page Middle Directory in the sequence of pointers are kept so that the same code can work on 32-bit and 64-bit architectures. The kernel keeps a position for the Page Upper Directory and the Page Middle Directory by setting the number of entries in them to 1 and mapping these two entries into the proper entry of the Page Global Directory.

Can someone explain this in a more palatable manner?

2
linuxmemory-managementkernelpaging
Okay, so I gave a little more thought and please see if this makes sense. So, basically, you have this MMU hardware which walks through the page hierarchy on TLB miss, for which essentially, the single entry PMD and PUD are oblivious. However, for the rest of the kernel code, we need to present a uniform interface of 4-level paging. So, we have a single entry PUD and a single entry PMD each of which are emulated to contain the exact same value of the corresponding PGD entry for that address. – subramanian
Yes. On processors without PAE, the MMU expects only the lower two tables, but the kernel expects all four, so the upper two have to be created with just one entry. Make sure you add your comment as an answer when you can. – ughoavgfhw
I think my explanation had holes Linuxios explains it clearly to me. so i will mark his answer as correct. – subramanian

2 Answers

2
votes

Well, I think what is meant is that the kernel always uses 4 levels of page tables, which can accommodate both normal 32 bit, PAE, and long mode. I think what they mean in the quote is that the PM4L and the PDT are just set to a length of one entry which just points to the next one down. So that means that in normal 32 bit, you get this:

                              /-> Page table
PM4L -> PDT -> Page Directory --> Page table
                              \-> Page table

But in PAE, you get this:

PM4L -> PDT -> 512 Page Directories -> 1024 Page tables

And in Long mode, you get this:

PM4L -> 512 PDTs -> 512 Page Directories -> 1024 Page tables

But because of the 4 levels always, the rest of the kernel has a unified interface across 32 bits, PAE, and long mode.

0
votes

At the moment I am reading the same book and I don't want to ask a new question because this one addresses exactly my problem.
The usual sequence of tables is the following:

PML4 (Linux: PGD) -> PDPT (Linux: PUD) -> PD (Linux: PMD) -> PT

In the text it is said that two levels are sufficient and that is why the PUD and the PMD are "eliminated" but any of this two tables has a length of one and is kept in the right order of the sequence.
In my understanding this means that the PML4 (PGD) corresponds to the PD (PMD) and consists of direct pointers to the PT. So the PUD and the PMD are "skipped". But my understanding doesn't correspond to the correct answer of the original question.
And how is such an address resolved if a 32-bit application does a syscall and switches into 64-bit kernel mode? In this case the MMU expects four layers and not two.
It is obvious that something is wrong with my understanding because things can't work like that. Hopefully someone could clear things up.