4 ms·
This makes it now 4x more expensive to catch memory issues by having guard pages around...
by malkia 1y ago
This makes it now 4x more expensive to catch memory issues by having guard pages around...
- fulafel 1y agoIn which currency? VA space is plentiful.
- nolist_policy 1y agoOnly 512Gb virtual address space an Android arm64...
- entropicdrifter 1y agoSorry, are you talking about a quantity of ram in bits, or did you just forget to capitalize the b in "GB"?
- AStonesThrow 1y ago“GB” would also be wrong in terms of RAM: you’re looking for “GiB”.
- shpx 1y agobibibytes are not going to happen
- junon 1y agoNot really. Guard pages don't actually cost any physical memory.
- malkia 1y agoThey do... each allocation that is protecting must be aligned by 4kb, and now by 16kb (ideally padded at end) On top of that, adding 4kb (or 16kb) pages sprinkled across adds more to the TLB cache.
- junon 1y agoGuard pages do not require physical pages, no. Just a page table entry. All pages are aligned by 4kib (except for esoteric CPUs perhaps). That's what a page is. Unless the guard page is on another page table boundary, no additional physical pages are required. Further, TLB cost means nothing if it's a guard page. It shouldn't be accessed in any normal path barring a bug.
- malkia 1y agoWhat I'm saying is that if you have relatively lots of small allocations, with the 4Kb page, they also have to be aligned by 4kb, and with the new android changes - it'll be 16kb (e.g. 4x more).