From: cr88192@gmail.com
On 12/12/2023 5:56 PM, Scott Lurndal wrote:
> James Harris writes:
>> On 23/03/2023 19:49, Dan Cross wrote:
>>> In article ,
>>> Scott Lurndal wrote:
>>>> cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>
>> ...
>>
>>>>> It was never clear to me
>>>>> how a hypervisor could, in general, know the format of the guest
>>>>> page tables. I know the Disco folks had to make some changes to
>>>>> Irix to get it to work.
>>>>
>>>> When I was working on IRIX, I was not fond of either the software
>>>> managed TLB, coloring or the Kseg stuff; the MIPS project I worked on was
called
>>>> Teak and was a distributed version of Irix (eventually cancelled)
>>>> for networks of R10k boxes.
>>>
>>> I get it from a hardware perspective: fewer transistors with a
>>> software-managed TLB, but man...so many drawbacks.
>>
>> Handling a software-managed TLB may be more work, in a sense, but it
>> gives an OS developer more control, more feedback, more freedom, and
>> perhaps better opportunities for performance gains - as long as the TLB
>> is large enough.
>>
>> Having the hardware carry out a walk of page tables (the only option if
>> the TLB can is updated by hardware) has long seemed to me like a bad
>> idea, and it doesn't scale very well as addresses get wider.
>
> Having worked extensively with both models (SW: MIPS, HW: pretty much
> every other single mass-produced microprocessor), there is, hands down,
> no benefit to software table walks. Zero. Zilch. Don't even bother.
>
> Hardware translation table walks scale rather well, and in modern
> incarnations (e.g. ARMv8) are very flexible, supporting multiple
> fundamental unit of translation sizes (e.g. 4k, 16k, 64k) and
> higher level "huge pages". Add in the second level of walks
> required for hardware VM guest page table walkers[*] and the software
> walker becomes fragile and slow. The hardware walkers have
> things like content addressible memory and intermediate translation
> walk caches that software cannot do as effectively or efficiently.
>
> [*] 22 distinct memory accesses to translate a guest VA using 4k pages for
> both the guest and nested page tables.
I will partly disagree:
Software TLB makes the hardware cheaper to implement (it raises an TLB
Miss exception and its job is done);
Also one can make the interrupt mechanism cheap (for hardware) as well
by treating it as a glorified branch-with-link (with the interrupt
handler needing to deal with everything else itself).
But, in terms of performance or ease-of-use, I will admit that hardware
page walks make this easier.
But, CPUs that are fast or not a pain to write OS level code for, are
not the only things that matter.
Claiming that there is no possible advantage to software TLB is like
arguing that there is no possible advantage to CPU's which only support
aligned memory access (and use slow emulation traps to deal with
unaligned access).
If there were no advantage, people wouldn't do it that way...
The main advantage of the flexibility of software TLB is that more
advanced features can be added without needing to pay for them in terms
of making the hardware more expensive (you merely pay for them in terms
of programmer effort and clock-cycles).
Then people can take the savings in one area, and spend them somewhere
else, say, like having a better FPU (or having an FPU at all), or maybe
even such extravagances as an integer-divide instruction.
But, all sort of a balancing act.
...
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
