linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* Should ppc32 use CONFIG_HIGHPTE or not?
@ 2009-05-01 18:37 Dave Hansen
  2009-05-01 20:14 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 2+ messages in thread
From: Dave Hansen @ 2009-05-01 18:37 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, Paul Mackerras

arch/powerpc/mm/pgtable_32.c has the following function:

pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long address)
{
        struct page *ptepage;

#ifdef CONFIG_HIGHPTE
        gfp_t flags = GFP_KERNEL | __GFP_HIGHMEM | __GFP_REPEAT | __GFP_ZERO;
#else
        gfp_t flags = GFP_KERNEL | __GFP_REPEAT | __GFP_ZERO;
#endif
...

But there's no trace of CONFIG_HIGHPTE anywhere in arch/powerpc.  But,
the one and only definition on 32-bit of pte_offset_map() (in
arch/powerpc/include/asm/pgtable-ppc32.h) seems to have HIGHPTE
semantics:

#define pte_offset_map(dir, addr)               \
        ((pte_t *) kmap_atomic(pmd_page(*(dir)), KM_PTE0) + pte_index(addr))
#define pte_offset_map_nested(dir, addr)        \
        ((pte_t *) kmap_atomic(pmd_page(*(dir)), KM_PTE1) + pte_index(addr))

So, it looks like ppc32 never actually allocates highmem pte pages, but
it *does* go to the trouble of at least trying to kmap_atomic() them.
Should we just give ppc32 unconditional direct-mapped ptes?  Or, should
we remove that #ifdef and let it allocate them in highmem when it can
since we also have the code to support that?

-- Dave

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Should ppc32 use CONFIG_HIGHPTE or not?
  2009-05-01 18:37 Should ppc32 use CONFIG_HIGHPTE or not? Dave Hansen
@ 2009-05-01 20:14 ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 2+ messages in thread
From: Benjamin Herrenschmidt @ 2009-05-01 20:14 UTC (permalink / raw)
  To: Dave Hansen; +Cc: linuxppc-dev, Paul Mackerras, Kumar Gala

On Fri, 2009-05-01 at 11:37 -0700, Dave Hansen wrote:

 .../...

> So, it looks like ppc32 never actually allocates highmem pte pages, but
> it *does* go to the trouble of at least trying to kmap_atomic() them.
> Should we just give ppc32 unconditional direct-mapped ptes?  Or, should
> we remove that #ifdef and let it allocate them in highmem when it can
> since we also have the code to support that?

We actually noticed that recently :-)

We implemented HIGHPTE support a long time ago, and then somebody
disabled HIGHPTE for both x86 and powerpc on the ground that it wasn't
reliable, I don't remember off hand who, I think it was in the 2.5.x
timeframe, and while it got re-enabled on x86 it never was on powerpc
(maybe because we never noticed it was disabled in the first place ;-)

Now, recently, some changes went in that could possibly be problematic
with HIGHPTE, at least I have a vague recollection of that, I think
Kumar was involved... Kumar, was this fixed ?

So depending on that, maybe we could revive the option ... or just
get rid of that HIGHPTE support and be done with it.

Cheers,
Ben.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-05-01 20:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-01 18:37 Should ppc32 use CONFIG_HIGHPTE or not? Dave Hansen
2009-05-01 20:14 ` Benjamin Herrenschmidt

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).