[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1242532500.9691.10.camel@pasglop>
Date: Sun, 17 May 2009 13:55:00 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Dave Hansen <dave@...ux.vnet.ibm.com>
Cc: linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
Kumar Gala <galak@...e.crashing.org>
Subject: Re: [RFC][PATCH 34/35] powerpc use generic ptemap.h
On Fri, 2009-05-01 at 07:42 -0700, Dave Hansen wrote:
> powerpc is a bid of an oddball here. It seems to have CONFIG_HIGHPTE
> behavior at all times when compiled as 32-bit. There's even an
> #ifdef CONFIG_HIGHPTE in arch/powerpc/mm/pgtable_32.c, but there's no
> trace of HIGHPTE in Kconfig anywhere.
>
> This gives ppc32 an explicit HIGHPTE in Kconfig so that we can use
> the #ifdef in asm-generic/ptemap.h and let ppc use the generic code
> with x86 and frv.
With a bit of lag as I was away...
> +config HIGHPTE
> + def_bool y
> + depends on HIGHMEM
> +
Make this a selectable option and mark it EXPERIMENTAL or something. I
wouldn't be surprised if some of our stuff bitrotted. Also I very much
doubt BookE 32-bit will cope with HIGHPTE since the TLB miss code runs
in virtual mode with only the linear mapping guaranteed to be available
and it's not re-entrant.
So at the very least, make it depends on 6xx and also mark it
EXPERIMENTAL.
Also, iirc (I'll have to dbl check), our recent changes to enable
freeing of PTE pages using RCU may have broken HIGHPTE due to abuse of
page_address() on PTE pages. Nothing unfixable but another reason not to
unconditionally enable it.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists