From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Becky Bruce <beckyb@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org, david@gibson.dropbear.id.au
Subject: Re: [PATCH 04/13] powerpc: Update hugetlb huge_pte_alloc and tablewalk code for FSL BOOKE
Date: Tue, 29 Nov 2011 16:25:33 +1100 [thread overview]
Message-ID: <1322544333.23348.69.camel@pasglop> (raw)
In-Reply-To: <1318279870278-git-send-email-beckyb@kernel.crashing.org>
On Mon, 2011-10-10 at 15:50 -0500, Becky Bruce wrote:
> From: Becky Bruce <beckyb@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.
next prev parent reply other threads:[~2011-11-29 5:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-10 20:50 [PATCH 0/13] Hugetlb for 64-bit Freescale Book3E Becky Bruce
2011-10-10 20:50 ` [PATCH 01/13] powerpc: Only define HAVE_ARCH_HUGETLB_UNMAPPED_AREA if PPC_MM_SLICES Becky Bruce
2011-10-10 20:50 ` [PATCH 02/13] powerpc: hugetlb: fix huge_ptep_set_access_flags return value Becky Bruce
2011-10-10 20:50 ` [PATCH 03/13] powerpc: Fix booke hugetlb preload code for PPC_MM_SLICES and 64-bit Becky Bruce
2011-10-10 20:50 ` [PATCH 04/13] powerpc: Update hugetlb huge_pte_alloc and tablewalk code for FSL BOOKE Becky Bruce
2011-10-10 20:50 ` [PATCH 05/13] powerpc: hugetlb: modify include usage for FSL BookE code Becky Bruce
2011-10-10 20:50 ` [PATCH 06/13] powerpc: Whitespace/comment changes to tlb_low_64e.S Becky Bruce
2011-10-10 20:50 ` [PATCH 07/13] powerpc: Add hugepage support to 64-bit tablewalk code for FSL_BOOK3E Becky Bruce
2011-10-10 20:50 ` [PATCH 08/13] powerpc: Add gpages reservation code for 64-bit FSL BOOKE Becky Bruce
2011-10-10 20:50 ` [PATCH 09/13] powerpc: Kconfig updates for FSL BookE HUGETLB 64-bit Becky Bruce
2011-10-10 20:50 ` [PATCH 10/13] powerpc: Update mpc85xx/corenet 32-bit defconfigs Becky Bruce
2011-10-10 20:50 ` [PATCH 11/13] powerpc: Enable Hugetlb by default for 32-bit 85xx/corenet Becky Bruce
2011-10-10 20:50 ` [PATCH 12/13] powerpc: Update corenet64_smp_defconfig Becky Bruce
2011-10-10 20:50 ` [PATCH 13/13] powerpc: Enable hugetlb by default for corenet64 platforms Becky Bruce
2011-10-12 4:29 ` [PATCH 12/13] powerpc: Update corenet64_smp_defconfig Kumar Gala
2011-10-12 4:29 ` [PATCH 10/13] powerpc: Update mpc85xx/corenet 32-bit defconfigs Kumar Gala
2011-12-09 22:05 ` Tabi Timur-B04825
2011-11-29 5:25 ` Benjamin Herrenschmidt [this message]
2011-11-29 16:36 ` [PATCH 04/13] powerpc: Update hugetlb huge_pte_alloc and tablewalk code for FSL BOOKE Becky Bruce
2011-11-30 1:10 ` David Gibson
2011-11-25 0:43 ` [PATCH 03/13] powerpc: Fix booke hugetlb preload code for PPC_MM_SLICES and 64-bit Benjamin Herrenschmidt
2011-11-28 16:01 ` Kumar Gala
2011-11-28 16:54 ` Becky Bruce
2011-11-28 22:50 ` Benjamin Herrenschmidt
2011-11-29 3:58 ` [PATCH 02/13] powerpc: hugetlb: fix huge_ptep_set_access_flags return value Benjamin Herrenschmidt
2011-11-29 16:52 ` Becky Bruce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1322544333.23348.69.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=beckyb@kernel.crashing.org \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).