131–140 of 173 posts
iOS has had 16K pages since forever. OSX switched to 16K pages in 2020 with the M1. Windows is stuck on 4K pages, even for AArch64. Linux has various page sizes. Asahi is 16K.
Windows has 4K, 2M, and 1G page sizes on x86-64.
I wonder who requested the 1G page size be implemented and what they use it for...
Earlier quoted context omitted.
Because of virtual address translation [1] speed up. When a memory access is made by a program, the CPU must first translate the virtual address to a physical address, by walking a hierarchical data structure called a page table [2]. Walking the page tables is slow, thus CPUs implement a small on-CPU cache of virtual-to-physical translations called a TLB [1]. The TLB has a limited number of entries for each page size…
Thanks! > I'm happy to talk about this all day! With noobs, too? ;) > Often, the CPU has different number of entries for each page size. - Does it mean userspace is free to allocate up to a maximum of 1G? I took pages to have a fixed size. - Or, you mean CPUs reserve TLB sizes depending on the requested page size? > With 2 MiB or 1 GiB pages, there is less contention and more workingset size is covered by the TLB - W…
Earlier quoted context omitted.
Because of virtual address translation [1] speed up. When a memory access is made by a program, the CPU must first translate the virtual address to a physical address, by walking a hierarchical data structure called a page table [2]. Walking the page tables is slow, thus CPUs implement a small on-CPU cache of virtual-to-physical translations called a TLB [1]. The TLB has a limited number of entries for each page size…
Thanks! > I'm happy to talk about this all day! With noobs, too? ;) > Often, the CPU has different number of entries for each page size. - Does it mean userspace is free to allocate up to a maximum of 1G? I took pages to have a fixed size. - Or, you mean CPUs reserve TLB sizes depending on the requested page size? > With 2 MiB or 1 GiB pages, there is less contention and more workingset size is covered by the TLB - W…
The TLB is a hardware cache with a limited number of entries that cannot dynamically change. Your CPU is shipped with a fixed number of entries dedicated for each page size. Translations of base 4 KiB pages could, for example, have 1024 entries. Translations of 2 MiB pages could have 512 entries and those of 1 GiB usually have a very limited number of only 8 or 16. Nowadays, most CPU vendors increased their 2 MiB TLBs to have the same number of entries dedicated for 4 KiB pages.
If you're wondering why they have to be separate caches, it's because, for any page in memory, you can have both mappings at the same time from different processes or different parts of the same process, with possibly different protections.
> - Would memory allocators / GCs need to be changed to deal with blocks of 1G? Would you say, the current ones found in popular runtimes/implementations are adept at doing so?
> - Does it not adversely affect databases accustomed to smaller page sizes now finding themselves paging in 1G at once?
Runtimes and databases have full control and Linux allows per-process policies via madvise) system call. If a program is not happy with huge pages, it can ask the kernel to be ignored, as it can choose to be cooperative.
> If the dissertation is public, please do link it, if you're comfortable doing so.
I'm still in the PhD process, so no cookies atm :D
Earlier quoted context omitted.
What? Any pointers on how 1G speeds things up? I'd have taken a bigger page size to wreak havoc on process scheduling and filesystem.
It's nice for type 1 hypervisors when carving up memory for guests. When page walks for guest virtual to host physical end up taking sixteen levels, a 1G page short circuits that in half to eight.
Earlier quoted context omitted.
A more relevant bit of background is that 4KB pages lead to quite a lot of overhead due to the sheer number of mappings needing to be configured and cached. Using larger pages reduce overhead, in particular TLB misses as fewer entries are needed to describe the same memory range. While x86 chips mainly supports 4K, 2M and 1G pages, ARM chips tend to support more practical 16K page sizes - a nice balance between perfo…
IIRC, 64-bit ARM can do 4K, 16K, 64K and 2M pages. But there are some special rules for the last one. https://documentation-service.arm.com/static/64d5f38f4a92140...
The size of the translation granule determines the size of the block entries at each level. So 4K granules has super pages of 2MB and 1GB, 16KB granules has 32MB super pages, and 64K has 512MB super pages.
Earlier quoted context omitted.
Why would an "Android news" blog mention what competitors are doing?
Because the whole thing sounds like they’re doing something new, but they’re just catching up to something Apple has done back when they switched to aarch64.
Earlier quoted context omitted.
Yes, but the context here is Java or Kotlin running on Android, not embedded C. Or do some Android applications run embedded C with only a Java UI? I'm not an Android dev.
Apps written in Flutter/Dart and React Native/Javascript both compile to native code with only shims to interface with the Java UI framework.
Also important to note that any code that runs on Android's ART runtime (i.e. Kotlin and/or Java) can get some or all of its code AOT-compiled to machine code by the OS, either upon app install (if the app ships with baseline profiles) or in the background while the device is idle and charging.
A little additional background: iOS has used 16KB pages since the 64-bit transition, and ARM Macs have inherited that design.
How is this "additional background"? This was a post by Google regarding Android.
Earlier quoted context omitted.
Windows has 4K, 2M, and 1G page sizes on x86-64.
Normal, large and huge. But default normal pages (which is what Android is changing) are 4K. FWIW, Itanium and Alpha had 8K default pages. https://devblogs.microsoft.com/oldnewthing/20210510-00/?p=10... I wonder why Microsoft stayed with 4K for AArch64.