5 ms·

> The very first 16 KB enabled Android system will be made available on select devices as a developer option. This is so you can use the developer option to tes

by a1o 2y ago

> The very first 16 KB enabled Android system will be made available on select devices as a developer option. This is so you can use the developer option to test and fix > once an application is fixed to be page size agnostic, the same application binary can run on both 4 KB and 16 KB devices I am curious about this. When could an app NOT be agnostic to this? Like what an app must be doing to cause this to be noticeable?

sweeter 2y ago
Wine doesn't work on 16 KB page size among other things.
- mananaysiempre 2y ago
  This seems especially peculiar given Windows has a 64K mapping granularity.
  - tredre3 2y ago
    Windows uses 4KB pages.
    - nullindividual 2y ago
      4K, 2M ("large page"), or 1G ("huge page") on x86-64. A single allocation request can consist of multiple page sizes. From Windows Internal 7th Edt Part 1: On Windows 10 version 1607 x64 and Server 2016 systems, large pages may also be mapped with huge pages, which are 1 GB in size. This is done automatically if the allocation size requested is larger than 1 GB, but it does not have to be a multiple of 1 GB. For example, an allocation of 1040 MB would result in using one huge page (1024 MB) plus 8 “normal” large pages (16 MB divided by 2 MB).
    - mananaysiempre 2y ago
      Right (on x86-32 and -64, because you can’t have 64KB pages there, though larger page sizes do exist and get used). You still cannot (e.g.) MapViewOfFile() on an address not divisible by 64KB, because Alpha[1]. As far as I understand, Windows is mostly why the docs for the Blink emulator[2] (a companion project of Cosmopolitan libc) tell you any programs under it need to use sysconf(_SC_PAGESIZE) [aka getpagesize() aka getauxval(AT_PAGESZ)] instead of assuming 4KB. [1] https://devblogs.microsoft.com/oldnewthing/20031008-00/?p=42223 https://devblogs.microsoft.com/oldnewthing/20031008-00/?p=42... [2] https://github.com/jart/blink/blob/master/README.md#compiling-and-running-programs-under-blink https://github.com/jart/blink/blob/master/README.md#compilin...
      - alephr 2y ago
        this is no longer true with MapViewOfFile3: Third time's a charm, now you can map to page boundaries
        mananaysiempre 2y ago
        TIL about MapViewOfFile3 and NtMapViewOfSectionEx, thanks! Still, the Microsoft docs say[1]: > [in, optional] BaseAddress > The desired base address of the view (the address is rounded down to the nearest 64k boundary). > [...] > [in] Offset > The offset from the beginning of the section. > The offset must be 64k aligned. The peculiar part is where base address and offset must be divisible by 64K (also referred to as the “allocation granularity”) but the size only needs to be divisible by the page size. Maybe you’re right and the docs are wrong?.. [1] https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-mapviewoffile3 https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
        alephr 2y ago
        the new behavior works under the MEM_REPLACE_PLACEHOLDER flag, you can create those regions with VirtualAlloc2
- blkhp19 2y ago
  Why does Wine work just fine on an M-series Mac then?
mlmandude 2y ago
If you use mmap/munmap directly within your application you could probably get into trouble by hardcoding the page size.
vardump 2y ago
For example use mmap and just assume 4 kB pages.
dmytroi 2y ago
Also ELF segment alignment, which is defaults to 4k.
- bri3d 2y ago
  Only on Android, for what it's worth; most "vanilla" Linux aarch64 linkers chose 64K defaults several years ago. But yes, most Android applications with native (NDK) binaries will need to be rebuilt with the new 16kb max-page-size.
edflsafoiewq 2y ago
jemalloc bakes in page size assumptions, see eg https://github.com/jemalloc/jemalloc/issues/467 https://github.com/jemalloc/jemalloc/issues/467.
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
saagarjha 2y ago
Pages sizes are often important to code that relies on low-level details of the environment it’s running in, like language runtimes. They might do things like mark some sections of code as writable or executable and thus would need to know what the granularity of those requests can be. It’s also of importance to things like allocators that hand out memory backed by mmap pages. If they have, say, a bit field for each 16-byte region of a page that has been used that will change in size in ways they can detect.
growse 2y ago
If you use a database library that does mmap to create a db file with SC_PAGE_SIZE (4KB) pages, and then upgrade your device to a 16KB one and backup/restore the app, now your data isn't readable.
- phh 2y ago
  Which is the reason you need to format your data to experiment with 16k
nox101 2y ago
I don't know if this fits but I've seen code that allocated say 32 bytes from a function that allocated 1meg under the hood. Not knowing that's what was happening the app quickly ran out of memory. It arguably was not the app's fault. The API it was calling into was poorly designed and poorly named, such that the fact that you might need to know the block size to use the function was in no way indicated by the name of the function nor the names of any of its parameters.
dataflow 2y ago
> When could an app NOT be agnostic to this When the app has a custom memory allocator, the allocator might have hardcoded the page size for performance. Otherwise you have to load a static variable (knocks out a cache line you could've used for something else) and then do a multiplication (or bit shift, if you assume power of 2) by a runtime value instead of a shift by a constant, which can be slower. No idea if Android apps are ever this performance sensitive, though.

by a1o 2y ago

sweeter 2y ago

Wine doesn't work on 16 KB page size among other things.

mananaysiempre 2y ago
This seems especially peculiar given Windows has a 64K mapping granularity.
- tredre3 2y ago
  Windows uses 4KB pages.
  - nullindividual 2y ago
    4K, 2M ("large page"), or 1G ("huge page") on x86-64. A single allocation request can consist of multiple page sizes. From Windows Internal 7th Edt Part 1: On Windows 10 version 1607 x64 and Server 2016 systems, large pages may also be mapped with huge pages, which are 1 GB in size. This is done automatically if the allocation size requested is larger than 1 GB, but it does not have to be a multiple of 1 GB. For example, an allocation of 1040 MB would result in using one huge page (1024 MB) plus 8 “normal” large pages (16 MB divided by 2 MB).
  - mananaysiempre 2y ago
    Right (on x86-32 and -64, because you can’t have 64KB pages there, though larger page sizes do exist and get used). You still cannot (e.g.) MapViewOfFile() on an address not divisible by 64KB, because Alpha[1]. As far as I understand, Windows is mostly why the docs for the Blink emulator[2] (a companion project of Cosmopolitan libc) tell you any programs under it need to use sysconf(_SC_PAGESIZE) [aka getpagesize() aka getauxval(AT_PAGESZ)] instead of assuming 4KB. [1] https://devblogs.microsoft.com/oldnewthing/20031008-00/?p=42223 https://devblogs.microsoft.com/oldnewthing/20031008-00/?p=42... [2] https://github.com/jart/blink/blob/master/README.md#compiling-and-running-programs-under-blink https://github.com/jart/blink/blob/master/README.md#compilin...
    - alephr 2y ago
      this is no longer true with MapViewOfFile3: Third time's a charm, now you can map to page boundaries
      - mananaysiempre 2y ago
        TIL about MapViewOfFile3 and NtMapViewOfSectionEx, thanks! Still, the Microsoft docs say[1]: > [in, optional] BaseAddress > The desired base address of the view (the address is rounded down to the nearest 64k boundary). > [...] > [in] Offset > The offset from the beginning of the section. > The offset must be 64k aligned. The peculiar part is where base address and offset must be divisible by 64K (also referred to as the “allocation granularity”) but the size only needs to be divisible by the page size. Maybe you’re right and the docs are wrong?.. [1] https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-mapviewoffile3 https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
        alephr 2y ago
        the new behavior works under the MEM_REPLACE_PLACEHOLDER flag, you can create those regions with VirtualAlloc2
blkhp19 2y ago
Why does Wine work just fine on an M-series Mac then?

mlmandude 2y ago

If you use mmap/munmap directly within your application you could probably get into trouble by hardcoding the page size.

vardump 2y ago

For example use mmap and just assume 4 kB pages.

dmytroi 2y ago

Also ELF segment alignment, which is defaults to 4k.

bri3d 2y ago
Only on Android, for what it's worth; most "vanilla" Linux aarch64 linkers chose 64K defaults several years ago. But yes, most Android applications with native (NDK) binaries will need to be rebuilt with the new 16kb max-page-size.

edflsafoiewq 2y ago

jemalloc bakes in page size assumptions, see eg https://github.com/jemalloc/jemalloc/issues/467 https://github.com/jemalloc/jemalloc/issues/467.

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

saagarjha 2y ago

Pages sizes are often important to code that relies on low-level details of the environment it’s running in, like language runtimes. They might do things like mark some sections of code as writable or executable and thus would need to know what the granularity of those requests can be. It’s also of importance to things like allocators that hand out memory backed by mmap pages. If they have, say, a bit field for each 16-byte region of a page that has been used that will change in size in ways they can detect.

growse 2y ago

If you use a database library that does mmap to create a db file with SC_PAGE_SIZE (4KB) pages, and then upgrade your device to a 16KB one and backup/restore the app, now your data isn't readable.

phh 2y ago
Which is the reason you need to format your data to experiment with 16k

nox101 2y ago

I don't know if this fits but I've seen code that allocated say 32 bytes from a function that allocated 1meg under the hood. Not knowing that's what was happening the app quickly ran out of memory. It arguably was not the app's fault. The API it was calling into was poorly designed and poorly named, such that the fact that you might need to know the block size to use the function was in no way indicated by the name of the function nor the names of any of its parameters.

dataflow 2y ago

> When could an app NOT be agnostic to this When the app has a custom memory allocator, the allocator might have hardcoded the page size for performance. Otherwise you have to load a static variable (knocks out a cache line you could've used for something else) and then do a multiplication (or bit shift, if you assume power of 2) by a runtime value instead of a shift by a constant, which can be slower. No idea if Android apps are ever this performance sensitive, though.