UMA MD Small Allocator Runtime Switching

[John Baldwin]

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