Re: free bootmem feedback patch

Josh Aas
2004-08-03T17:53:53Z

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.

wli - do you still want to see the memory map for my big test machine
(512GB RAM)?

-Josh

Luck, Tony wrote:
>>>still be looking at a couple of minutes :-( Since I only got a
>>>55% reduction, rather than a factor of 64 I expect that modifying
>>>to look an larger order pages may have diminishing returns.
>>
>>I'll work relative to this for the rest. I'd recommend using __ffs()
>>instead of the loop. Also, combining this with a specialized page
>>freeing function that doesn't e.g. fiddle with page references
>
>
> The returns to freeing larger pages do indeed diminish fast. I
> added simple "look at the next word" and "look at the next
> three words" hacks to see what the times looked like with
> order=7 and order=8 ... and found that order 8 is only 1.8%
> faster than order 6.
>
>
>>The common case is the bitmap and mem_map[] starting at 0.
>
>
> Sadly not quite 0. PG_reserved is set for each page structure
> and must be cleared ... so we have to touch every page structure
> at least once :-( On a 4TB machine thats 0.25 billion cache
> misses (with a 16K page).
>
>
>
>>remaining cases are pretty marginalized. This can actually be checked
>>at runtime by checking the alignment of ->node_boot_start, e.g. maybe
>>if (!~v && !((__pa(bdata->node_boot_start) >> PAGE_SHIFT) &
>>((1 << MAX_ORDER) - 1)))
>>instead of just !~v.
>
>
> That check can be done once (for each node) outside the loop. The
> exact expression used to set the "gofast" variable in my patch
> make need some tweaking
>
> New patch attached.
>
> -Tony

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