4 ms·

Can someone with RISC-V and CPU background do an ELI5 and why this is interesting/important?

by artemonster 5y ago

kragen 5y ago
I don't understand it but it looks like an extension for 64k hugepages?
- monocasa 5y ago
  It's a a generic solution for page size to be within a range of aligned power of two sizes, but only the bit pattern specifying 64k isn't reserved at the moment. It'll allow for all sorts of page sizes with fairly minimal TLB overhead when it's all said and done, rather than normal huge pages that tend to only increase in page table radix size (eg. on x86_64, 512x each level, ie. 4k->2MB->1GB granularity). It's real handy for reducing TLB overhead in the general case for the same reasons as why newer archs have larger pages, but in a way that shouldn't require a given os instance to have one base page table size so you don't need to recompile/port older programs that want 4k pages.
  - pm215 5y ago
    The twitter thread says it specifically doesn't change the size of a page, though. AIUI the idea is that it allows one TLB entry to cover more than just one page -- the page table entry promises "all 64K have the same permissions", so the TLB doesn't need to track every page in that 64K separately. That's useful because TLB entries are a limited resource and using more of them means we get more TLB misses and worse peformance. You could also economise on TLB use by making the page size larger, but then it has to be larger for the whole process, which has binary-compatibility implications and also can waste memory (eg with a 64K page size, even if you only need 4K to mmap a small file you have to use 64K anyway). Compare the Arm page table 'contiguous hint bit', which achieves the same thing in a slightly different way.
    - deleted 5y ago
      [deleted]
    - monocasa 5y ago
      Technically true, but code running on those mappings won't be able to tell the difference. Another way to look at it is that the page size does change, but the size of the page table entry expands at the same rate, and you can therefore mix and match page sizes. They're equivalent concepts.

Can someone with RISC-V and CPU background do an ELI5 and why this is interesting/important?

kragen 5y ago

I don't understand it but it looks like an extension for 64k hugepages?

monocasa 5y ago
It's a a generic solution for page size to be within a range of aligned power of two sizes, but only the bit pattern specifying 64k isn't reserved at the moment. It'll allow for all sorts of page sizes with fairly minimal TLB overhead when it's all said and done, rather than normal huge pages that tend to only increase in page table radix size (eg. on x86_64, 512x each level, ie. 4k->2MB->1GB granularity). It's real handy for reducing TLB overhead in the general case for the same reasons as why newer archs have larger pages, but in a way that shouldn't require a given os instance to have one base page table size so you don't need to recompile/port older programs that want 4k pages.
- pm215 5y ago
  The twitter thread says it specifically doesn't change the size of a page, though. AIUI the idea is that it allows one TLB entry to cover more than just one page -- the page table entry promises "all 64K have the same permissions", so the TLB doesn't need to track every page in that 64K separately. That's useful because TLB entries are a limited resource and using more of them means we get more TLB misses and worse peformance. You could also economise on TLB use by making the page size larger, but then it has to be larger for the whole process, which has binary-compatibility implications and also can waste memory (eg with a 64K page size, even if you only need 4K to mmap a small file you have to use 64K anyway). Compare the Arm page table 'contiguous hint bit', which achieves the same thing in a slightly different way.
  - deleted 5y ago
    [deleted]
  - monocasa 5y ago
    Technically true, but code running on those mappings won't be able to tell the difference. Another way to look at it is that the page size does change, but the size of the page table entry expands at the same rate, and you can therefore mix and match page sizes. They're equivalent concepts.