On 24.01.2009 23:21 Uhr, Carl-Daniel Hailfinger wrote:
> On 24.01.2009 20:58, Stefan Reinauer wrote:
>
>> Carl-Daniel Hailfinger wrote:
>>
>>
>>> Example:
>>> We want to cache 0MB - (2G-64M-64k).
>>>
>>>
>>>
>> Where do the 64k come from?
>>
>>
>
> That was specific to Jason's setup. IIRC the 64k were ACPI memory or
> somesuch.
>
Any reason why that shouldn't be cachable?
From a memory perspective, it's just normal memory, not graphics memory
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: [email protected] • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
