Attached is an improved version of Tony Luck's patch. It shaves another 
~25% off by not using atomic ops to clear the page reserved bits and 
prefetching. Tony - will you sign off on it with me and we'll get this in?

Unfortunately, this still leaves a ~1 minute delay with no indication of 
what is going on for 4TB machines, and ~2 minutes for 8TB. Thus, I'd 
still like to see my progrees indicator patch go in. I am guessing 
memory sizes are only going to get bigger than even 8 TB, and memory is 
not going to get faster at the rate the totals increase (it certainly 
didn't double in speed between 4 and 8 TB installations). Thoughts?

Signed-off-by: Josh Aas <josha@sgi.com>

-Josh

William Lee Irwin III wrote:
> On Tue, Aug 03, 2004 at 12:53:53PM -0500, Josh Aas wrote:
> 
>>Are there any outstanding issues with Tony's second revision of the 
>>free_all_bootmem_core function? Do we still have the problem of making 
>>sure longwork in node_bootmem_map[] corresponds to an order 6 page with 
>>the right physical alignment? The second revision looks good to me. If I 
>>could get some more feedback on it I'll clean up any remaining issues so 
>>it can land sometime soon. I'll post test results (unpatched vs. 
>>patched) on a big machine later this afternoon.
> 
> 
> I think it's fine.
> 
> On Tue, Aug 03, 2004 at 12:53:53PM -0500, Josh Aas wrote:
> 
>>wli - do you still want to see the memory map for my big test machine 
>>(512GB RAM)?
> 
> 
> Sure.
> 
> 
> -- wli

-- 
Josh Aas
Silicon Graphics, Inc. (SGI)
Linux System Software
651-683-3068