From: ThatWouldBeTelling@thevillage.com
Scott Lurndal wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> EricP writes:
>>> There were a number of proposals around then, the paper I linked to
>>> also suggested injecting the miss routine into the ROB.
>>> My idea back then was a HW thread.
> the same problem.
Not quite.
My idea was to have two HW threads HT1 and HT2 which are like x86 HW
threads except when HT1 gets a TLB miss it stalls its execution and
injects the TLB miss handler at the front of HT2 pipeline,
and a HT2 TLB miss stalls itself and injects its handler into HT1.
The TLB miss handler never itself TLB misses as it explicitly checks
the TLB for any VA it needs to translate so recursion is not possible.
As the handler is injected at the front of the pipeline no drain occurs.
The only possible problem is if between when HT1 injects its miss handler
into HT2 that HT2's existing pipeline code then also does a TLB miss.
As this would cause a deadlock, if this occurs then it cores detects it
and both HT fault and run their TLB miss handler themselves.
>>> While HW walkers are serial for translating one VA,
>>> the translations are inherently concurrent provided one can
>>> implement an atomic RMW for the Accessed and Modified bits.
>> It's always a one-way street (towards accessed and towards modified,
>> never the other direction), so it's not clear to me why one would want
>> atomicity there.
>
> To avoid race conditions with software clearing those bits, presumably.
>
> ARM64 originally didn't support hardware updates in V8.0, they were
> independent hardware features added to V8.1.
Yes. A memory recycler can periodically clear the Accessed bit
so it can detect page usage, and that might be a different core.
But it might skip sending TLB shootdowns to all other cores
to lower the overhead (maybe a lazy usage detector).
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
