Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] FRV: Change PML4 -> PUD | Date | Wed, 05 Jan 2005 12:16:43 +0000 |
| |
Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> David Howells wrote: > > The attached patch changes the PML4 bits of the FRV arch to the new PUD way. > > > > Looks OK... any reason you aren't using the asm-generic folding headers? > (asm-generic/pgtable-nopmd.h or asm-generic/pgtable-nopud.h).
The PMEs aren't that trivial. Technically, I think I should have one PGE containing 64 PMEs, each of which points to one chunk of a common page table, but I'm not sure the allocation assumptions will work right for that.
The way the page table tree structure is defined on this arch is interesting: 16KB PGD, 256B PTs and 16KB pages. I glue several PTs together into one page, which means that each PME actually contains 64 pointers and is 256B in size.
Trying to use the trivial PUD/PMD support buys me compilation errors about being unable to represent objects. It would be easier if the support wasn't inside out: pmd_t contains a pud_t which contains a pgd_t. This perhaps should be the other way around.
The problems seem to revolve around this:
#define set_pgd(pgdptr, pgdval) \ set_pud((pud_t *)(pgdptr), (pud_t) { pgdval })
It's probably possible to rewrite the thing so that the pgd_t contains the 64 pointers, but then set_pmd() ends up setting the pgd_t which seems wrong somehow. Not only that, but the code looks wrong: pmd->pud->pgd?????
It would seem better to me to start from the assumption that PMEs will always contain "pointers" to page tables. What the current method seems to do is that pointers to page tables are installed as high up the tree as possible, and the unnecessary dangly bits (PUDs/PMDs) are looped back on themselves.
Both methods work, I suppose, but it's not well documented; and because it's inside out, it's not immediately obvious. Whoever designed this system should write it up and stick a file in Documentation/ about it.
> I sent some notes to the arch list about getting those working, but > apparently it hasn't come though yet.
Sounds like there's a mailing list I should be on, but don't know about.
> Of course I do think it is sensible that you just get it working first, > before getting too fancy.
Definitely. The arch makes "fancy" tricky anyway.
David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |