1. I do not see why they say that optional huge pages do not help.
It helps with TLB hit rate as you have more mapped with the same number of TLB entries.
It helps with access latency as you need to access fewer levels before reaching a leaf entry.
Minor page faults are reduced as you map larger ranges so fewer faults are needed to reload the system state.
L1 cache size I concede.
The power consumption argument just seems to be related to L1 cache size again which I can not speak to.
I/O transfer size should also be able to take advantage of the large ranges.
2. I do not see how their proposal is any different than the already existing ARMv8 contiguous bit which is a hint to the TLB that it can cache a bunch of leaf entries as a single entry. In fact, the proposal here appears to be even more limited because it requires alignment.
It helps with TLB hit rate as you have more mapped with the same number of TLB entries.
It helps with access latency as you need to access fewer levels before reaching a leaf entry.
Minor page faults are reduced as you map larger ranges so fewer faults are needed to reload the system state.
L1 cache size I concede.
The power consumption argument just seems to be related to L1 cache size again which I can not speak to.
I/O transfer size should also be able to take advantage of the large ranges.
2. I do not see how their proposal is any different than the already existing ARMv8 contiguous bit which is a hint to the TLB that it can cache a bunch of leaf entries as a single entry. In fact, the proposal here appears to be even more limited because it requires alignment.