From: james.harris.1@nospicedham.gmail.com
On 08/04/2019 14:59, Terje Mathisen wrote:
> James Harris wrote:
>> On 07/04/2019 07:24, Rod Pemberton wrote:
>>> On Thu, 4 Apr 2019 22:35:12 +0100
>>> James Harris wrote:
>>>
>>>> Anyone know how portably to test an x86 PC's memory?
>>>
>>> What do you mean by "portably" here? Reliable methods? Multiple
>>> generations of processors? Universal software sequence?
>>> All-of-the-above?
>>
>> Certainly they would need to be reliable methods which covered multiple
>> generations of processors and took account of various types of installed
>> cache memory.
>>
>> As for a 'universal software sequence', depending on what you mean, a
>> single approach would be ideal but it may be necessary to have the code
>> select different paths for different hardware. I say that because any
>> one method may not work on all machines.
>>
>> For example, Terje suggested writing four times as much RAM as there is
>> cache. The problems I have with that are
>>
>> * Why 'four' times?
>
> I wanted to suggest 8 times, since the highest associativity of any
> cache I have seen was 8, but this is almost certainly not needed as long
> as you are accessing a memory block which is many times larger than the
> last level cache.
Ah, OK. That's assuming the level of cache nearest the RAM is LRU. I
don't know about all the Intel cache controllers but caches /can/
operate a random replacement strategy (which is arguably less
susceptible than LRU to predictable thrashing). I guessed that you maybe
suggested four times to make it more likely that a two-way cache would
have its earlier contents written out.
>
>> * How to tell how much cache there is on such machines
>
> CPUID if an x86, and this is after all c.l.a.x86
> :-)
Agreed, though there are different situations even on x86.
1. A CPU prior to those having CPUID but with an external cache (which
would probably be write-through, given the era, though may be write-back).
For that I think I would need to determine the cache size at the outset
- possibly via repeatedly doubling an amount of RAM accessed in a loop
and checking the timings.
2. A CPU prior to CPUID without an external cache.
Doesn't sound like a problem, you might think, as all writes would go
directly to RAM but the above test (for case 1) of timing would keep
doubling the amount of RAM being tested without noticing a change in
test speed. So it could be hard to tell whether there was an external
cache or not.
3. A CPU with CPUID but no MTRRs. That could have an external cache
which CPUID doesn't describe.
4. A machine with MTRRs. I would assume that any machine of that sort
would have sufficient coordination between CPU and external caches (if
any) that the Uncacheable setting could be enforced.
The problem cases are the early machines.
--
James Harris
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
