Date: Wed, 13 Aug 2008 12:14:43 -0400 From: John Baldwin <jhb@freebsd.org> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: UMA MD Small Allocator Runtime Switching Message-ID: <200808131214.43326.jhb@freebsd.org> In-Reply-To: <48A2E62A.9060604@freebsd.org> References: <48981C19.8060009@freebsd.org> <200808051024.27043.jhb@freebsd.org> <48A2E62A.9060604@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 13 August 2008 09:48:26 am Nathan Whitehorn wrote: > John Baldwin wrote: > > On Tuesday 05 August 2008 05:23:37 am Nathan Whitehorn wrote: > >> I'm working on the PowerPC G5 port right now, and have run into a > >> problem with the way the UMA small allocator works. On G3/G4 systems, > >> there is a direct physical->virtual mapping, and on G5s there isn't. All > >> of the infrastructure is in place to support both types of system with a > >> single kernel image, except that UMA_MD_SMALL_ALLOC must be switched > >> on/off at runtime. > >> > >> One solution is to put if (direct_map) use_nonsmall_case() into the MD > >> small_alloc/free() routines and define UMA_MD_SMALL_ALLOC everywhere. > >> This works well, except that the MI UMA code then sets booted = 1 too > >> early in the boot process, before the kmem_alloc*() routines are available. > >> > >> Basically, I need to find a way have an MD UMA allocator without the MI > >> UMA code assuming anything about how it works internally. Maybe adding a > >> UMA_MD_ALLOC_LATE define to prevent setting booted=1 early on? > >> -Nathan > > > > Have you considered creating an artificial direct map region in the address > > space on the G5? Some of the other 64-bit ports (amd64 and sparc64) do this > > to gain the benefits of the direct map even though it isn't a mandated part > > of the architecture like it is on some other platforms (alpha and mips). > > I thought about it, but we can only use 4K pages on the G5 so this would > put a large amount of pressure on the page table. IBM removed the block > translation mechanism from the G5 and the CPU's superpage support is not > available in the 32-bit compatibility mode under which we currently run. Hmm, I didn't know you weren't running in full 64-bit mode. Is that a property of the G5 CPU that it only supports the 32-bit compat mode with 64-bit extensions? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808131214.43326.jhb>