Hi Matthew, I fixes up most of the comments. On Tue, Jun 6, 2023 at 5:57 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > On Tue, Jun 06, 2023 at 12:10:35AM +0200, Linus Walleij wrote: > > +- **pte**, `pte_t`, `pteval_t` = **Page Table Entry** - mentioned earlier. > > + The name is a bit confusing because while in Linux 1.0 this did refer to a > > + single page table entry in the top level page table, it was retrofitted > > + to be "what the level above points to". So when two-level page tables were > > + introduced, the *pte* became a list of pointers, which is why > > + `PTRS_PER_PTE` exists. This oxymoronic term can be mildly confusing. > > I don't think this is right. PTRS_PER_PTE is how many pointers are in > the PMD page table, I don't get this. What does PTRS_PER_PMD mean then (and then all the way up to PTRS_PER_PGD...) > so it's how many pointers you can walk if you have a > pte *. Yes, it's complicated and confusing, but I don't think this > explanation clears up any of that confusion. I will try to reword it so this gets through. > > +pointers*, so the **pgd** contains `PTRS_PER_PGD` pointers to the next level > > +below, **p4d** contains `PTRS_PER_P4D` pointers to **pud** items and so on. The > > +number of pointers on each level is architecture-defined. The most usual layout > > I don't think it's helpful to say this. It's really not that usual > (maybe half of our architectures behave that way?) > > I think a document like this that talks about page tables really needs to > include a description of how some PMDs / PUDs / ... may not be pointers > to lower levels, but direct pointers to the actual memory (ie THPs / > hugetlb pages). I don't understand that stuff. I suggest you patch this into the document when the basics are in place. > Sorry to take a wrecking ball to this, I'm sure you worked hard on it. Don't worry about that, I'm an academic, I just rewrite. Yours, Linus Walleij
