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