Adding 16 kb page size to Android • Hacker News Board

Re: Adding 16 kb page size to Android

#11

Post by arghwhat » Fri, Aug 23, 2024, 5:57 PM UTC

twoodfin wrote: post #4

A little additional background: iOS has used 16KB pages since the 64-bit transition, and ARM Macs have inherited that design.

A more relevant bit of background is that 4KB pages lead to quite a lot of overhead due to the sheer number of mappings needing to be configured and cached. Using larger pages reduce overhead, in particular TLB misses as fewer entries are needed to describe the same memory range.

While x86 chips mainly supports 4K, 2M and 1G pages, ARM chips tend to support more practical 16K page sizes - a nice balance between performance and wasting memory due to lower allocation granularity.

Nothing in particular to do with Apple and iOS.

Re: Adding 16 kb page size to Android

#12

Post by mrbuttons454 » Fri, Aug 23, 2024, 6:00 PM UTC

ashkankiani wrote: post #3

monocasa wrote: post #2

I wonder how much help they had by asahi doing a lot of the kernel and ecosystem work anablibg 16k pages. RISC-V being fixed to 4k pages seems to be a bit of an oversight as well.

It's pretty cool that I can read "anablibg" and know that means "enabling." The brain is pretty neat. I wonder if LLMs would get it too. They probably would.

Until I read your comment I didn't even notice...

Re: Adding 16 kb page size to Android

#13

Post by evilduck » Fri, Aug 23, 2024, 6:01 PM UTC

ashkankiani wrote: post #3

monocasa wrote: post #2

I wonder how much help they had by asahi doing a lot of the kernel and ecosystem work anablibg 16k pages. RISC-V being fixed to 4k pages seems to be a bit of an oversight as well.

It's pretty cool that I can read "anablibg" and know that means "enabling." The brain is pretty neat. I wonder if LLMs would get it too. They probably would.

Question I wrote:

> I encountered the typo "anablibg" in the sentence "I wonder how much help they had by asahi doing a lot of the kernel and ecosystem work anablibg 16k pages." What did they actually mean?

GPT-4o and Sonnet 3.5 understood it perfectly. This isn't really a problem for the large models.

For local small models:

* Gemma2 9b did not get it and thought it meant "analyzing".

* Codestral (22b) did not it get it and thought it meant "allocating".

* Phi3 Mini failed spectacularly.

* Phi3 14b and Qwen2 did not get it and thought it was "annotating".

* Mistral-nemo thought it was a portmanteau "anabling" as a combination of "an" and "enabling". Partial credit for being close and some creativity?

* Llama3.1 got it perfectly.

Re: Adding 16 kb page size to Android

#14

Post by edflsafoiewq » Fri, Aug 23, 2024, 6:02 PM UTC

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…

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

Re: Adding 16 kb page size to Android

#15

Post by im3w1l » Fri, Aug 23, 2024, 6:03 PM UTC

ashkankiani wrote: post #3

monocasa wrote: post #2

I wonder how much help they had by asahi doing a lot of the kernel and ecosystem work anablibg 16k pages. RISC-V being fixed to 4k pages seems to be a bit of an oversight as well.

It's pretty cool that I can read "anablibg" and know that means "enabling." The brain is pretty neat. I wonder if LLMs would get it too. They probably would.

I asked chatgpt and it did get it.

Personally, when I read the comment my brain kinda skipped over the word since it contained the part "lib" I assumed it was some obscure library that I didn't care about. It doesn't fit grammatically but I didn't give it enough thought to notice.

Re: Adding 16 kb page size to Android

#16

Post by platelminto » Fri, Aug 23, 2024, 6:05 PM UTC

mrob wrote: post #6

ashkankiani wrote: post #3

Earlier quoted context omitted.

It's pretty cool that I can read "anablibg" and know that means "enabling." The brain is pretty neat. I wonder if LLMs would get it too. They probably would.

LLMs are at a great disadvantage here because they operate on tokens, not letters.

I remember reading somewhere that LLMs are actually fantastic at reading heavily mistyped sentences! Mistyped to a level where humans actually struggle.

(I will update this comment if I find a source)

Re: Adding 16 kb page size to Android

#17

Post by jandrese » Fri, Aug 23, 2024, 6:05 PM UTC

evilduck wrote: post #13

ashkankiani wrote: post #3

Earlier quoted context omitted.

It's pretty cool that I can read "anablibg" and know that means "enabling." The brain is pretty neat. I wonder if LLMs would get it too. They probably would.

Question I wrote: > I encountered the typo "anablibg" in the sentence "I wonder how much help they had by asahi doing a lot of the kernel and ecosystem work anablibg 16k pages." What did they actually mean? GPT-4o and Sonnet 3.5 understood it perfectly. This isn't really a problem for the large models. For local small models: * Gemma2 9b did not get it and thought it meant "analyzing". * Codestral (22b) did not it ge…

Seems like there is a bit of a roll of the dice there. The ones that got it right may have just been lucky.

Re: Adding 16 kb page size to Android

#18

Post by sweeter » Fri, Aug 23, 2024, 6:08 PM UTC

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…

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

Re: Adding 16 kb page size to Android

#19

Post by jsheard » Fri, Aug 23, 2024, 6:09 PM UTC

arghwhat wrote: post #11

twoodfin wrote: post #4

A little additional background: iOS has used 16KB pages since the 64-bit transition, and ARM Macs have inherited that design.

A more relevant bit of background is that 4KB pages lead to quite a lot of overhead due to the sheer number of mappings needing to be configured and cached. Using larger pages reduce overhead, in particular TLB misses as fewer entries are needed to describe the same memory range. While x86 chips mainly supports 4K, 2M and 1G pages, ARM chips tend to support more practical 16K page sizes - a nice balance between perfo…

Makes me wonder how much performance Windows is leaving on the table with its primitive support for large pages. It does support them, but it doesn't coalesce pages transparently like Linux does, and explicitly allocating them requires special permissions and is very likely to fail due to fragmentation if the system has been running for a while. In practice it's scarcely used outside of server software which immediately grabs a big chunk of large pages at boot and holds onto them forever.

Re: Adding 16 kb page size to Android

#20

Post by thanatropism » Fri, Aug 23, 2024, 6:13 PM UTC

platelminto wrote: post #16

mrob wrote: post #6

Earlier quoted context omitted.

LLMs are at a great disadvantage here because they operate on tokens, not letters.

I remember reading somewhere that LLMs are actually fantastic at reading heavily mistyped sentences! Mistyped to a level where humans actually struggle. (I will update this comment if I find a source)

Tihs probably refers to comon mispelllings an typo's.