On Thu, Sep 23, 2004 at 03:12:40PM -0700, Luck, Tony wrote: > > >I am not sure what will be acceptable at this point. Should I write > >an uncached allocator which grabs the granules at boot time before they > >are ever initialized for cacheable use? If so, would it be acceptable > >to just shrink each efi memory map entry by a command line specified > >size during the efi_memmap_walk callout? At this point I am so vague > >on what I should be doing that I am afraid to do much of anything. > > We already make adjustments to the efi memory map (to trim sections to > granule boundaries) ... but another hack on top of the layers of ugliness > there already is going to make things worse. Perhaps someday we can > delete it all and start over. > > Grabbing your memory out of the map before any of the rest of Linux > ever sees it sounds to be a good idea ... it avoids wasting memory > for page structures in mem_map that can only get you into trouble > if anyone ever looks at them. > > If your allocator only needs a small number of pages from each node, then > it is possible that you'd be able to feed it the trimmed off scraps > from incomplete granules, rather than pull a whole granule. So you > might want to run your scan through the efi map before anyone else > messes with it. Sounds like I have a direction. I will try to put together a patch tomorrow morning to at least get the discussion started. Thanks, Robin - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Thu Sep 23 19:16:36 2004
This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:31 EST