Re: [PATCH] FRV: Change PML4 -> PUD

[David Howells]

Nick Piggin <nickpiggin@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/