Date: Wed, 07 May 2008 08:18:50 -0700 From: Peter Grehan <grehan@freebsd.org> To: Nathan Whitehorn <nathanw@uchicago.edu> Cc: freebsd-ppc@freebsd.org Subject: Re: UMA_MD_SMALL_ALLOC Message-ID: <4821C85A.7090605@freebsd.org> In-Reply-To: <4821C6AB.3080101@uchicago.edu> References: <4821C6AB.3080101@uchicago.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Nathan, > In doing the G5 port, I have a problem with the UMA_MD_SMALL_ALLOC > option. Because the G5 does not have BAT, this is broken. Even if we > were to emulate it with pages, this is not a useful thing to have, since > the point of the option would be defeated. But removing it would > pessimize the G3/G4 port (the AIM code also panics late in boot without > it, but that is a separate issue). > > There doesn't seem to be a way to twiddle it at runtime, which is a > major problem if we want to have a single kernel running on all OEA > machines. So I'm not sure what to do. Thoughts? A long time ago I talked to Alan Cox about modifying this option so it could be done at run-time, and he seemed agreeable. The mips port has a similar issue in that only the lower 512MB of RAM is direct-mapped, so a run-time decision would help them too (though it would be based on free pages and not processor variant). > Also, an update on the G5 port: the PMAP stuff is done to the point > where the kernel boots all the way to panicing about not having a PIC, > which is late in the boot process and implies that only device support > remains. Trap handling is up and running as well. And (with the > exception of UMA_MD_SMALL_ALLOC) the same kernel also boots on my G3. Fantastic ! Post some patches, I'll give it a try. Have you changed the sync_icache code to dynamically switch to 128 bytes for the G5 ? later, Peter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4821C85A.7090605>