On Sat, Jan 26, 2002 at 01:20:45AM +0100, Benjamin Herrenschmidt wrote:
> >
> >Looking at bat_mapin_ram, it looks like we only map the first 512MB of
> >RAM with BATs, so we actually map the 512MB - 768MB range with PTEs
> >(and highmem starts at 768MB). Two of the DBATs are used by I/O
> >mappings, so that only leaves two DBATs of 256MB each to map lowmem
> >anyway. Am I missing something?
>
> No, except maybe my last patch that actually limits lowmem to 512Mb ;)
:)
> I don't think we use the io mapping BATs any more, do we ? (well,
> maybe on PReP...) I don't on pmac.
Lots and lots of PPC platforms use BATs for io mappings:
val@evilcat </sys/linuxppc_2_4_devel_pristine/arch/ppc/platforms>$ grep -l ppc_md.setup_io_mappings *
grep: SCCS: Is a directory
adir_setup.c
apus_setup.c
chrp_setup.c
gemini_setup.c
k2_setup.c
lopec_setup.c
mcpn765_setup.c
menf1_setup.c
mvme5100_setup.c
pcore_setup.c
powerpmc250.c
pplus_setup.c
prep_setup.c
prpmc750_setup.c
prpmc800_setup.c
sandpoint_setup.c
spruce_setup.c
zx4500_setup.c
I'm trying to get highmem working on Gemini, hence my interest.
> >By the way, does the "nobats" option currently work on PowerMac?
>
> No, nor on any other BAT-capable PPC (and that's the reason why I
> did the above). Basically, our exception return path and some of
> the hash manipulation functions aren't safe without BAT mapping,
> especially on SMP when you can get evicted from the hash table
> by the other CPU in places where taking hash faults isn't safe.
Hm, that's what I thought. Thanks for confirming that.
-VAL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:00:44 EST