On Nov 13, 2008, at 10:32 PM, Yuri Tikhonov wrote:

On Tuesday, November 11, 2008 Milton Miller wrote:

quoted

quoted

quoted

quoted

 #ifdef CONFIG_PTE_64BIT
 typedef unsigned long long pte_basic_t;
+#ifdef CONFIG_PPC_256K_PAGES
+#define PTE_SHIFT       (PAGE_SHIFT - 7)

This seems to be missing the comment on how many ptes are actually 
in
the page that are in the other if and else cases.

Ok. I'll fix this. Actually it's another hack: we don't use full page
for PTE table because we need to reserve something for PGD

quoted

I don't understand "we need to reserve something for PGD".   Do you
mean that you would not require a second page for the PGD because the
full pagetable could fit in one page?

...

quoted

That does imply you want to allocate the pte page from a slab instead
of pgalloc.  Is that covered?

 Well, in case of 256K PAGE_SIZE we do not need the PGD level indeed
(18 bits are used for offset, and remaining 14 bits are for PTE index
inside the PTE table). Even the full 256K PTE page isn't necessary to
cover the full range: only half of it would be enough (with 14 bits we
can address only 16K PTEs).

 But the head_44x.S code is essentially based on the assumption of
2-level page addressing. Also, I may guess that eliminating of the
PGD level won't be as easy as just a re-implementation of the TLB-miss
handlers in head_44x.S. So, the current approach for 256K-pages
support was just a compromise between the required for the project
functionality, and the effort necessary to achieve it.

So are you allocating the < PAGE_SIZE levels from slabs (either kmalloc 
or dedicated) instead of allocating pages?   Or are you wasting the 
extra space?

At a very minimum you need to comment this in the code.  If I were 
maintiner I would say not wasting large fractions of pages when the 
page size is 256k would be my merge requirement.  As I said, I'm fine 
with keeping the page table two levels, but the tradeoff needs to be 
documented.

milton