[HN Gopher] New RISC-V Svnapot Extension
___________________________________________________________________
New RISC-V Svnapot Extension
Author : hasheddan
Score : 18 points
Date : 2021-12-31 16:29 UTC (1 days ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| artemonster wrote:
| Can someone with RISC-V and CPU background do an ELI5 and why
| this is interesting/important?
| kragen wrote:
| I don't understand it but it looks like an extension for 64k
| hugepages?
| monocasa wrote:
| 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 wrote:
| 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.
| monocasa wrote:
| 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.
| [deleted]
| metadat wrote:
| Man these twitter "Blog Posts" are tough to read, especially on
| mobile devices.
|
| After getting through the Install-Our-App nag _:
|
| There is so much visual noise, reading the article one or two
| sentences at a time and scrolling constantly is a totally
| disjointed experience for me.
|
| Sucks because I am in fact interested in this topic and would
| like to broaden my understanding!
|
| Sorry for the rant.
|
| Happier New Year to you all!
|
| --
|
| _ Twitter's incessant modal dialogue app-install nag is a form of
| punishment / user-abuse, because the company should know by now,
| based on the _dozens of previous rejections:_ I 'm not
| interested! Too much trouble to set a goddamn cookie? Asshole
| product managers and their prescious "metrics" are running
| (ruining) the show.
___________________________________________________________________
(page generated 2022-01-01 23:02 UTC)