4 ms·

The fundamental problem is that system headers don't provide enough information. In particular, many programs need both "min runtime page size" and "max runtime

by o11c 2y ago

The fundamental problem is that system headers don't provide enough information. In particular, many programs need both "min runtime page size" and "max runtime page size" (and by this I mean non-huge pages). If you call `mmap` without constraint, you need to assume the result will be aligned to at least "min runtime page size". In practice it is probably safe to assume 4K for this for "normal" systems, but I've seen it down to 128 bytes on some embedded systems, and I don't have much breadth there (this will break many programs though, since there are more errno values than that). I don't know enough about SPARC binary compatibility to know if it's safe to push this up to 8K for certain targets. But if you want to call `mmap` (etc.) with full constraint, you must work in terms of "max runtime page size". This is known to be up to at least 64K in the wild (aarch64), but some architectures have "huge" pages not much beyond that so I'm not sure (256K, 512K, and 1M; beyond that is almost certainly going to be considered huge pages). Besides a C macro, these values also need to be baked into the object file and the linker needs to prevent incompatible assumptions (just in case a new microarchitecture changes them)

dotancohen 2y ago
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.
- saagarjha 2y ago
  Android apps can call into native code via JNI, which the platform supports.
  - ignoramous 2y ago
    Wonder if Android apps can also be fully native (C++)?
    - extraduder_ire 2y ago
      I saw a project posted on here a while back about writing android apps with no java, only c. There is no good reason to do it, but it is apparently possible. https://github.com/cnlohr/rawdrawandroid https://github.com/cnlohr/rawdrawandroid
    - fensgrim 2y ago
      It is possible to have a project set up with a manifest which contains only a single activity with android.app.NativeActivity pointing to a .so, and zero lines of java/kotlin/flutter/whatever else - though your app initialization will go through usual hoops of spawning a java-based instance. Minimal example would be https://github.com/android/ndk-samples/blob/master/native-activity/app/src/main/AndroidManifest.xml https://github.com/android/ndk-samples/blob/master/native-ac..., though there are well established Qt based apps as well
- orf 2y ago
  Yes, Android apps can and do have native libraries. Sometimes this can be part of a SDK, or otherwise out of the developers control.
- warkdarrior 2y ago
  Apps written in Flutter/Dart and React Native/Javascript both compile to native code with only shims to interface with the Java UI framework.
  - farmerbb 2y ago
    Flutter/Dart, yes, React Native/Javascript, no. With RN the app's code runs via an embedded JavaScript engine, and even when, say, Hermes is being used, it's still executing bytecode not native machine code. 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.
- david_allison 2y ago
  The Android Native Development Kit (NDK) allows building native code libraries for Android (typically C/C++, but this can include Rust). These can then be loaded and accessed by JNI on the Java/Kotlin side * Brief overview of the NDK: https://developer.android.com/ndk/guides https://developer.android.com/ndk/guides * Guide to supporting 16KB page sizes with the NDK https://developer.android.com/guide/practices/page-sizes https://developer.android.com/guide/practices/page-sizes
  - dotancohen 2y ago
    Good to know, thank you!
- fpoling 2y ago
  Chrome browser on Android uses the same code base as Chrome on desktop including multi-process architecture. But it’s UI is in Java communicating with C++ using JNI.
  - dotancohen 2y ago
    I had no idea, thank you!
lanigone 2y ago
you can also do 2M and 1G huge pages on x86, it gets kind of silly fast.
- ShroudedNight 2y ago
  1G huge pages had (have?) performance benefits on managed runtimes for certain scenarios (Both the JIT code cache and the GC space saw uplift on the SpecJ benchmarks if I recall correctly) If using relatively large quantities of memory 2M should enable much higher TLB hit rates assuming the CPU doesn't do something silly like only having 4 slots for pages larger than 4k ¬.¬
- ignoramous 2y ago
  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.
  - afr0ck 2y ago
    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. With 4 KiB pages, the contention on this cache is very high, especially if the workload has a very large workingset size, therefore causing frequent cache evictions and slow walk of the page tables. With 2 MiB or 1 GiB pages, there is less contention and more workingset size is covered by the TLB. For example, a TLB with 1024 entries can cover a maximum of 4 MiB of workingset memory. With 2 MiB pages, it can cover up to 2 GiB of workingset memory. Often, the CPU has different number of entries for each page size. However, it is known that larger page sizes have higher internal fragmentation and thus lead to memory wastage. It's a trade off. But generally speaking, for modern systems, the overhead of managing memory in 4 KiB is very high and we are at a point where switching to 16/64 KiB is almost always a win. 2 MiB is still a bit of a stretch, though, but transparent 2 MiB pages for heap memory is enabled by default on most major Linux distributions, aka THP [2] Source: my PhD is on memory management and address translation on large memory systems, having worked both on hardware architecture of address translation and TLBs as well as the Linux kernel. I'm happy to talk about this all day! [1] https://blogs.vmware.com/vsphere/2020/03/how-is-virtual-memory-translated-to-physical-memory.html https://blogs.vmware.com/vsphere/2020/03/how-is-virtual-memo... [2] https://docs.kernel.org/admin-guide/mm/transhuge.html https://docs.kernel.org/admin-guide/mm/transhuge.html

by o11c 2y ago

dotancohen 2y ago

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.

saagarjha 2y ago
Android apps can call into native code via JNI, which the platform supports.
- ignoramous 2y ago
  Wonder if Android apps can also be fully native (C++)?
  - extraduder_ire 2y ago
    I saw a project posted on here a while back about writing android apps with no java, only c. There is no good reason to do it, but it is apparently possible. https://github.com/cnlohr/rawdrawandroid https://github.com/cnlohr/rawdrawandroid
  - fensgrim 2y ago
    It is possible to have a project set up with a manifest which contains only a single activity with android.app.NativeActivity pointing to a .so, and zero lines of java/kotlin/flutter/whatever else - though your app initialization will go through usual hoops of spawning a java-based instance. Minimal example would be https://github.com/android/ndk-samples/blob/master/native-activity/app/src/main/AndroidManifest.xml https://github.com/android/ndk-samples/blob/master/native-ac..., though there are well established Qt based apps as well
orf 2y ago
Yes, Android apps can and do have native libraries. Sometimes this can be part of a SDK, or otherwise out of the developers control.
warkdarrior 2y ago
Apps written in Flutter/Dart and React Native/Javascript both compile to native code with only shims to interface with the Java UI framework.
- farmerbb 2y ago
  Flutter/Dart, yes, React Native/Javascript, no. With RN the app's code runs via an embedded JavaScript engine, and even when, say, Hermes is being used, it's still executing bytecode not native machine code. 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.
david_allison 2y ago
The Android Native Development Kit (NDK) allows building native code libraries for Android (typically C/C++, but this can include Rust). These can then be loaded and accessed by JNI on the Java/Kotlin side * Brief overview of the NDK: https://developer.android.com/ndk/guides https://developer.android.com/ndk/guides * Guide to supporting 16KB page sizes with the NDK https://developer.android.com/guide/practices/page-sizes https://developer.android.com/guide/practices/page-sizes
- dotancohen 2y ago
  Good to know, thank you!
fpoling 2y ago
Chrome browser on Android uses the same code base as Chrome on desktop including multi-process architecture. But it’s UI is in Java communicating with C++ using JNI.
- dotancohen 2y ago
  I had no idea, thank you!

lanigone 2y ago

you can also do 2M and 1G huge pages on x86, it gets kind of silly fast.

ShroudedNight 2y ago
1G huge pages had (have?) performance benefits on managed runtimes for certain scenarios (Both the JIT code cache and the GC space saw uplift on the SpecJ benchmarks if I recall correctly) If using relatively large quantities of memory 2M should enable much higher TLB hit rates assuming the CPU doesn't do something silly like only having 4 slots for pages larger than 4k ¬.¬
ignoramous 2y ago
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.
- afr0ck 2y ago
  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. With 4 KiB pages, the contention on this cache is very high, especially if the workload has a very large workingset size, therefore causing frequent cache evictions and slow walk of the page tables. With 2 MiB or 1 GiB pages, there is less contention and more workingset size is covered by the TLB. For example, a TLB with 1024 entries can cover a maximum of 4 MiB of workingset memory. With 2 MiB pages, it can cover up to 2 GiB of workingset memory. Often, the CPU has different number of entries for each page size. However, it is known that larger page sizes have higher internal fragmentation and thus lead to memory wastage. It's a trade off. But generally speaking, for modern systems, the overhead of managing memory in 4 KiB is very high and we are at a point where switching to 16/64 KiB is almost always a win. 2 MiB is still a bit of a stretch, though, but transparent 2 MiB pages for heap memory is enabled by default on most major Linux distributions, aka THP [2] Source: my PhD is on memory management and address translation on large memory systems, having worked both on hardware architecture of address translation and TLBs as well as the Linux kernel. I'm happy to talk about this all day! [1] https://blogs.vmware.com/vsphere/2020/03/how-is-virtual-memory-translated-to-physical-memory.html https://blogs.vmware.com/vsphere/2020/03/how-is-virtual-memo... [2] https://docs.kernel.org/admin-guide/mm/transhuge.html https://docs.kernel.org/admin-guide/mm/transhuge.html