161–170 of 173 posts
Good. It's about time. 4KB pages come down to us from 32-bit time immemorial. We didn't bump the page size when we doubled the sizes of pointers and longs for the 64-bit transition. 4KB has been way too small for ages, and I'm glad we're biting the minor compatibility bullet and adopting a page size more suited to modern computing.
Earlier quoted context omitted.
Having both 4KB and 16KB simultaneously is either easy or hard depending on which hardware feature they are using for 16KB pages. If they are using the configurable granule size, then that is a system-wide hardware configuration option. You literally can not map at smaller granularity while that bit is set. You might be able to design a CPU that allows your idea of partial pages, but there be dragons. If they are not…
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...
Earlier quoted context omitted.
The CPU has hardware that does a page table walk automatically when you access an address for which the translation is not cached in the TLB. Otherwise virtual memory would be really slow. Since the CPU hardware itself is doing the page table walk it needs to understand page tables and page table entries etc. including how big pages are. Also you need to know how big pages are for the TLB itself. The value of 4kB its…
As an aside, it's shame that hardware page table walking won out over software filled TLBs, as some older computers had. I wonder what clever and wonderful hacks we might have been able to invent had we not needed to give the CPU a raw pointer to a data structure the layout of which is fixed forever.
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…
why does it break userland? if you need to know the page size, you should query sysconf SC_PAGESIZE.
Earlier quoted context omitted.
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 interestin…
Not entirely related (except the block size), but I am considering making and standardizing a system-wide content-based cache with default block size 16KB. The idea is that you'd have a system-wide (or not) service that can do two or three things: - read 16KB block by its SHA256 (also return length that can be - write a block to cache - maybe pin a block (e.g. make it non-evictable) I would be like a block-level file…
I would go for higher than 16K. I believe BitTorrent's default minimum chunk size is 64K, for example. It really depends on the use case in question though, if you're doing random writes then larger chunk sizes quickly waste a ton of bandwidth, especially if you're doing recursive rewrites of a tree structure. Would a variable chunk size be acceptable for whatever it is you're building?
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.
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.
Earlier quoted context omitted.
why does it break userland? if you need to know the page size, you should query sysconf SC_PAGESIZE.
Replacing compile time constants with function calls will always bring some trouble, suddenly you need to rearrange your structures, optimizations get missed (in extreme cases you can accidentally introduce a DIV instruction), etc. So it is not surprising that code assumes 4k pages.
Even for non-powers-of-two there are also techniques to speed up divisions if the same divisor is used repeatedly.