On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote: > From: Becky Bruce <bec...@kernel.crashing.org> > > This updates the hugetlb page table code to handle 64-bit FSL_BOOKE. > The previous 32-bit work counted on the inner levels of the page table > collapsing.
Seriously, my brain hurts !!! So I've tried to understand that code and so far, what I came up with is this, please reply and let me know if I'm full of crack or what ... - David's code has entire levels "branching off" into hugepd's which are hugetlb specific page dirs. That requires address space constrainst. - The hack you do with HUGEPD_PGD_SHIFT defined to PGDIR_SHIFT and HUGEPD_PUD_SHIFT to PUD_SHIFT consists of collasping that back into the normal levels. - I really don't understand what you are doing in __hugepte_alloc(). It seems to me that you are trying to make things still point to some kind of separate hugepd dir with the hugeptes in it and have the page tables point to that but I don't quite get it. - Couldn't we just instead ditch the whole hugepd concept alltogether and simply have the huge ptes in the page table at the right level, using possibly multiple consecutive of them for a single page when needed ? Example: 4K base page size. PMD maps 2M. a 16M page could be representing by having 8 consecutive hugeptes pointing to the same huge page in the PMD directory. I believe we always "know" when accessing a PTE whether it's going to be huge or not and if it's huge, the page size. IE. All the functions we care about either get the vma (which gets you everything you need) or the size (huge_pte_alloc). This should be much simpler than what we have today. That way, we have a completely generic accross-the-board way to store huge pte's in our page tables, which is totally disconnected from the slices. The later remains a purely server-only thing which only affects the SLB code and get_unmapped_area(). That means that we'll have to find another option for PowerEN giant indirects but that's a non issue at the moment. I think we can keep the complexity local to the PowerEN code by doing shadows there if we need to. What do you think ? Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
