From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [3/6] Allow more flexible layouts for hugepage pagetables
Date: Tue, 27 Oct 2009 14:10:59 +1100 [thread overview]
Message-ID: <1256613059.11607.18.camel@pasglop> (raw)
In-Reply-To: <20091016052212.E1DE0B7BBD@ozlabs.org>
On Fri, 2009-10-16 at 16:22 +1100, David Gibson wrote:
So far haven't seen anything blatantly wrong, in fact, this patch
results in some nice cleanups.
One thing tho...
> -#ifdef CONFIG_HUGETLB_PAGE
> - /* Handle hugepage regions */
> - if (HPAGE_SHIFT && mmu_huge_psizes[psize]) {
> - DBG_LOW(" -> huge page !\n");
> - return hash_huge_page(mm, access, ea, vsid, local, trap);
> - }
> -#endif /* CONFIG_HUGETLB_PAGE */
> -
> #ifndef CONFIG_PPC_64K_PAGES
> /* If we use 4K pages and our psize is not 4K, then we are hitting
> * a special driver mapping, we need to align the address before
> @@ -961,12 +954,18 @@ int hash_page(unsigned long ea, unsigned
> #endif /* CONFIG_PPC_64K_PAGES */
You basically made the above code be run with huge pages. This may not
be what you want ... It will result in cropping the low EA bits probably
at a stage where you don't want that (it might also be a non-issue, I
just want you to double check :-)
I suppose one option would be to remove that alignment and duplicate
the PTEs when creating those "special" mappings (afaik the only user
is spufs using 64K pages to map the local store)
Cheers,
Ben.
next prev parent reply other threads:[~2009-10-27 3:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-16 5:21 [0/6] Assorted hugepage cleanups (v3) David Gibson
2009-10-16 5:22 ` [3/6] Allow more flexible layouts for hugepage pagetables David Gibson
2009-10-27 3:10 ` Benjamin Herrenschmidt [this message]
2009-10-27 4:56 ` David Gibson
2009-10-16 5:22 ` [2/6] Cleanup management of kmem_caches for pagetables David Gibson
2009-10-27 2:28 ` Benjamin Herrenschmidt
2009-10-27 3:46 ` David Gibson
2009-10-27 4:30 ` Benjamin Herrenschmidt
2009-10-16 5:22 ` [1/6] Make hpte_need_flush() correctly mask for multiple page sizes David Gibson
2009-10-16 5:22 ` [5/6] Split hash MMU specific hugepage code into a new file David Gibson
2009-10-16 5:22 ` [6/6] Bring hugepage PTE accessor functions back into sync with normal accessors David Gibson
2009-10-16 5:22 ` [4/6] Cleanup initialization of hugepages on powerpc David Gibson
-- strict thread matches above, loose matches on Subject: below --
2009-10-27 5:22 [0/6] Assorted hugepage cleanups (v4) David Gibson
2009-10-27 5:24 ` [3/6] Allow more flexible layouts for hugepage pagetables David Gibson
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=1256613059.11607.18.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@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).