Sun Dec 9 17:34:17 CET 2012
or some such.
This might even be caused by my high tables patch from recently, but it
looks like a bug to me.
>>> However, a subtractive setup is not always more efficient.
>> Is it not? It sounds like at least if we have 2^x bytes of memory and
>> subtract a small chunk or two, we would be quite well off with it.
> Assuming you don't have anything you want to cache near 4 GB (like flash):
> Both strategies are equally efficient if the contiguous cacheable area
> has a size of 2^n+2^(n-1).
> The additive strategy is more efficient if the size is 2^n+2^(n-k) and k>1.
> The subtractive strategy is more efficient if the size is 2^n-2^(n-k)
> and k>1.
> I hope that you accept this without a detailed mathematical proof. ;-)
So in a setup with 2 equally sized DIMMs or only one DIMM, and possibly
UMA the subtractive method will always be the way to go.
>>> That means we
>>> have to select the best setup type. I devised a slightly tricky
>>> algorithm to do that:
>>> 1. Check if there are multiple disjoint cached areas in a given
>>> power-of-two sized area.
>>> 1a. If no, go to step 2
>>> 1b. If yes, stop here. Need advanced setup not described here.
>> please describe ;)
> 1b. Take the largest contiguous power-of-2 sized natually aligned chunk.
> Use additive setup for that chunk. Look at the remaining area. Does it
> still contain two disjoint chunks? If yes, go to 1b. If no, go to 2.
>>> 2. additive_count=bitcount(top_cached_addr+1)
>>> 4. if (additive_count>subtractive_count) go to subtractive_method else
>>> go to additive_method
>> Yes, sounds good.
> Glad to hear that. I hope the rest of the algorithm is OK for you as well.
Thinking about it again I'm not sure we're ever going to see multiple
disjoint cached areas in a given 2^x sized area. That would be... UMA in
the middle of the memory or something? Uh.. or more than 4G of memory?
coresystems GmbH â¢ Brahmsstr. 16 â¢ D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 â¢ Fax: +49 761 7664613
Email: info at coresystems.de â¢ http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg â¢ HRB 7656
GeschÃ¤ftsfÃ¼hrer: Stefan Reinauer â¢ Ust-IdNr.: DE245674866
More information about the coreboot