No subject

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)
>>> 3.
>>> subtractive_count=bitcount(rounduptonextpowerof2(top_cached_addr)-(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