Adding 16 kb page size to Android • Hacker News Board

Re: Adding 16 kb page size to Android

#141

Post by nullindividual » Sat, Aug 24, 2024, 4:34 AM UTC

CalChris wrote: post #118

afr0ck wrote: post #111

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…

Are huge pages expected to share code (X) and data (RW)?

Quoting Windows Internals 7th Edt Part 1:

    There is an unfortunate side effect of large pages. Each page (whether huge, large, or small) must be mapped with a single protection that applies to the entire page. This is because hardware memory protection is on a per-page basis. If a large page contains, for example, both read-only code and read/write data, the page must be marked as read/write, meaning that the code will be writable. As a result, device drivers or other kernel-mode code could, either maliciously or due to a bug, modify what is supposed to be read-only operating system or driver code without causing a memory access violation.

Re: Adding 16 kb page size to Android

#142

Post by nullindividual » Sat, Aug 24, 2024, 4:42 AM UTC

temac wrote: post #85

Const-me wrote: post #40

Earlier quoted context omitted.

> The one I notice the most is the filesystem I’m not sure it’s the file system per se, I believe the main reason is the security model. NT kernel has rather sophisticated security. The securable objects have security descriptors with many access control entries and auditing rules, which inherit over file system and other hierarchies according to some simple rules e.g. allow+deny=deny. Trustees are members of multipl…

I've been trying to use auditing rules for a usage that seems completely in scope and obvious to prioritize from a security point of view (tracing access to EFS files and/or the keys allowing the access) and my conclusion was that you basically can't, the doc is garbage, the implementation is probably ad-hoc with lots of holes, and MS probably hasn't prioritised the maintenance of this feature since several decades (…

From an NTFS auditing perspective, there’s no difference between auditing a non-EFS file or EFS file. Knowing that file auditing works just fine having done it many times, what makes you say it doesn’t work?

Re: Adding 16 kb page size to Android

#143

Post by nullindividual » Sat, Aug 24, 2024, 4:46 AM UTC

CalChris wrote: post #129

nullindividual wrote: post #128

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.

I was confused as to why you were posting incorrect information when this thread already contained the correct information.

Re: Adding 16 kb page size to Android

#144

Post by saagarjha » Sat, Aug 24, 2024, 5:40 AM UTC

Veserv wrote: post #114

sweetjuly wrote: post #102

Earlier quoted context omitted.

Hmm, I'm not sure that's quite right. ARMv8 supports per TTBR translation granules [1] and so you can have 4K and 16K user processes coexisting under an arbitrary page size kernel by just context switching TCR.TG0 at the same time as TTBR0. There is no such thing as a global granule size. [1]: https://arm.jonpalmisc.com/2023_09_sysreg/AArch64-tcr_el2#fi...

Well, if you want to run headfirst into the magical land of hardware errata, I guess you could go around creating heterogeneous, switched mappings. I doubt the TCRs were ever intended to support rapid runtime switching or that the TLBs were ever intended to support heterogeneous entrys even with ASID tagging.

Apple has been literally doing this for years.

Re: Adding 16 kb page size to Android

#145

Post by saagarjha » Sat, Aug 24, 2024, 5:42 AM UTC

username81 wrote: post #45

devit wrote: post #41

Seems pretty dubious to do this without adding support for having both 4KB and 16KB processes at once to the Linux kernel, since it means all old binaries break and emulators which emulate normal systems with 4KB pages (Wine, console emulators, etc.) might dramatically lose performance if they need to emulate the MMU. Hopefully they don't actually ship a 16KB default before supporting 4KB pages as well in the same ke…

Shouldn't there be some kind of setting to change the page size per program? AFAIK AMD64 CPUs can do this.

Yes, ARM CPUs can do it too.

Re: Adding 16 kb page size to Android

#146

Post by saagarjha » Sat, Aug 24, 2024, 5:47 AM UTC

taeric wrote: post #74

I see they have measured improvements in the performance of some things. In particular, the camera app starts faster. Small percentage, but still real. Curious if there are any other changes you could do based on some of those learnings? The camera app, in particular, seems like a good one to optimize to start instantly. Especially so with the the shortcut "double power key" that many phones/people have setup. Specif…

A big part of the challenge for launching the camera app is getting the hardware ready and quickly freeing up RAM for image processing.

Re: Adding 16 kb page size to Android

#147

Post by Dylan16807 » Sat, Aug 24, 2024, 6:02 AM UTC

afr0ck wrote: post #130

versteegen wrote: post #117

Earlier quoted context omitted.

> I'm happy to talk about this all day! Oh really :) I'd like to ask how applications should change their memory allocation or usage patterns to maximise the benefit of THP. Do memory allocators (glibc mainly) need config tweaking to coalesce tiny mallocs into 2MB+ mmaps, will they just always do that automatically, do you need to use a custom pool allocator so you're doing large allocations, or are you never going t…

In current Linux systems, there are two main ways to benefit from huge pages. 1) There is the explicit, user-managed approach via hugetlbfs. That's not very common. 2) Transparently managed by the kernel via THP (userpsace is completely unaware and any application using mmap() and malloc() can benefit from that). As I mentioned before, most major Linux distributions ship with THP enabled by default. THP automatically…

Mimalloc has support for huge pages. It also has an option to reserve 1GB pages on program start, and I've had very good performance results using that setting and replacing factorio's allocator. On windows and linux.

Re: Adding 16 kb page size to Android

#148

Post by arghwhat » Sat, Aug 24, 2024, 6:55 AM UTC

bewaretheirs wrote: post #93

arghwhat wrote: post #21

Earlier quoted context omitted.

Quite a bit, but 2M is an annoying size and the transparent handling is suboptimal. Without userspace cooperating, the kernel might end up having to split the pages at random due to an unfortunate unaligned munmap/madvise from an application not realizing it was being served 2M pages. Having Intel/AMD add 16-128K page support, or making it common for userspace to explicitly ask for 2M pages for their heap arenas is l…

Intel's menu of page sizes is an artifact of its page table structure. On x86 in 64-bit mode, page table entries are 64 bits each; the lowest level in the hierarchy (L1) is a 4K page containing 512 64-bit of PTEs which in total map 2M of memory, which is not coincidentally the large page size. The L1 page table pages are themselves found via a PTE in a L2 page table; one L2 page table page maps 512*2M = 1G of virtual…

Hmm? Pretending the page size is larger than it is would not yield the primary performance benefits of reduced TLB misses. Unless I am missing something, that seems more like a hack to save a tiny bit of kernel memory on a constrained system by having two PTE’s backed by the same internal page structure.

Unless we can change the size of the smallest page entry on Intel, I doubt there is room to do anything interesting there. If we could do like ARM and just multiply all the page sizes by 4 you would avoid any “shoehorning”.

Re: Adding 16 kb page size to Android

#149

Post by phh » Sat, Aug 24, 2024, 6:57 AM UTC

growse wrote: post #61

a1o wrote: post #7

> 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 noticea…

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.

Which is the reason you need to format your data to experiment with 16k

Re: Adding 16 kb page size to Android

#150

Post by iam-TJ » Sat, Aug 24, 2024, 7:36 AM UTC

In Debian kernel we've very recently enabled building an ARM64 kernel flavour with 16KiB page size and we've discussed adding a 64KiB flavour at some point as is the case for PowerPC64 already.

This will likely reveal bugs that need fixing in some of the 70,000+ packages in the Debian archive.

That ARM64 16KiB page size is interesting in respect of the Apple M1 where Asahi [0] identified that the DART IOMMU has a minimum page size of 16KiB so using that page size as a minimum for everything is going to be more efficient.

[0] https://asahilinux.org/2021/10/progress-report-september-202...