61–70 of 70 posts
Weird. AFAIK 4K and 64K were the common ARM64 page sizes, and 16K was the odd "think different" one that Apple uses. No mention of 16K in the Linux kernel docs: https://www.kernel.org/doc/html/next/arm64/memory.html
Earlier quoted context omitted.
I am not familiar with Android, but Linux ELF binaries that specify 4KB alignment will not work on systems with 16KB page sizes, since the ELF interpreter will refuse to load them. This hit me recently when trying to run a 32-bit binary on a Linux ARM system that had 16KB size pages, since the 32-bit OpenSSL libraries specified 4KB alignment. Presumably, this was done for maximizing entropy available to ASLR, but it…
Page size impacts page permissions; it's not a matter of wasting 12k, it's that with 4kb pages you're allowed to have a consecutive 8kb region with different permissions. 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare.
If you're making the migration at all, you really ought to be going for fully variable page sizes, otherwise 5 years from now there'll be a 64K page size CPU and suddenly everyone has to recompile everything again and there is another compatibility wall...
Earlier quoted context omitted.
Page size impacts page permissions; it's not a matter of wasting 12k, it's that with 4kb pages you're allowed to have a consecutive 8kb region with different permissions. 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare.
That's a valid point, but isn't memory protection the only common user-visible effect of changed page sizes? It would seem most apps which do not use write-protected memory would be unaffected.
A less safe option would be for permissions to be a union in that region, as code rarely depends on a permission being absent. That would be quite the security hole though.
Earlier quoted context omitted.
A lot of software wont work if you do that. Many jits and memory allocators have opinions on page size. Also tagged pointers are very common.
Memory page size should be transparent for tagged pointers (any pointers, really), I don't see how they can be affected. You have an object at address 0xAB0BA, does the size of underlying page matter?
1. You have a redis instance with e.g. 1GB of mapped memory in one 1GB huge page
2. Redis forks a copy of itself when it tries to persist data to disk so it can avoid having to lock the entire dataset for writes
3. The new Redis process does anything to modify any of the data anywhere in that 1GB
4. The OS has to now allocate a new 1GB page and copy the entire data set over
5. Oops, we're under memory pressure! Better page out 1GB of data to the paging file, or flush 1GB of data from the filesystem cache, so that I can allocate this 1GB page for the next 200ms.
You could imagine how memory allocators that try to be intelligent about what they're allocating and how much in order to optimize performance might care; when a custom allocator is trying to allocate many small pages and keep them in a pool so it can re-use them without having to request new pages from the OS, getting 100x 2M pages instead of 100x 4k pages is a colossal waste of memory and (potentially) performance.
It's not necessarily that the allocators will break or behave in weird, incorrect ways (they may) but often that the allocators will say "I can't work under these conditions!" (or will work but sub-optimally).
This is dumb. The abstraction is at the wrong level. Applications should assume the page size is 1 byte. One should be able to map, protect, etc memory ranges down to byte granularity - which is the granularity of everything else in computers. One fewer thing for programmers to worry about. History has shown that performance hacks with ongoing complexity tend not to survive (eg. interlaced video). At the hardware lev…
Earlier quoted context omitted.
Is anything industrial is going to be built on Android. There are no ATM's, no manufacturing CNC machines etc. One my say everything that runs on Android is throw away. It is only recently Samsung and Google started to aim at 7 year life spans. At 7 years for an industrial piece of equipment, I may not have even paid it off as yet, then again is the software on these things even updated?
Point of sale systems, like Toast. Media systems on airplanes. Infotainment systems in cars. In fact, NCR does sell an Android-based ATM solution. [1] Android is actually used somewhat widely in embedded systems that need to provide a nice GUI to the user. [1]: https://www.zdnet.com/article/ncr-launches-kalpana-an-androi...
Earlier quoted context omitted.
Memory page size should be transparent for tagged pointers (any pointers, really), I don't see how they can be affected. You have an object at address 0xAB0BA, does the size of underlying page matter?
It can be an issue of behavior; for example, Redis recommended disabling transparent huge page support in Linux because of (among other things?) copy-on-write memory page behaviors, and still does if you're going to persist data to disk. 1. You have a redis instance with e.g. 1GB of mapped memory in one 1GB huge page 2. Redis forks a copy of itself when it tries to persist data to disk so it can avoid having to lock…
Earlier quoted context omitted.
As a user not involved in android or linux development: I don't care. Fix it. You just don't break the entire ecosystem of unmaintained apps for a 3% performance improvement. We maintained win32-x86 executable compatibility for decades. Keeping things working might require some sort of emulation layer, and it might impact performance substantially, and that's fine. I can accept that. "Everything just stops working" i…
I think most apps are written in Java, and according to the blog post will not be affected. It's only the apps written in c++ that need to be compiled, and those are probably large games and heavily performance critical apps.
I suspect that code reuse of existing libraries not written in Java is another important use case.
Weird. AFAIK 4K and 64K were the common ARM64 page sizes, and 16K was the odd "think different" one that Apple uses. No mention of 16K in the Linux kernel docs: https://www.kernel.org/doc/html/next/arm64/memory.html