←back to thread

95 points ingve | 1 comments | | HN request time: 0.208s | source
Show context
londons_explore ◴[] No.44568753[source]
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 level, rather than picking a certain number of bits of the address as the page size, you have multiple page tables, and multiple TLB caches - eg. one for 1 megabyte pages, one for 4 kilobyte pages, and one for individual byte pages. The hardware will simultaneously check all the tables (parallelism is cheap in hardware!).

The benefit of this is that, assuming the vast majority of bytes in a process address space are made of large mappings, you can fit far more mappings in the (divided up) TLB - which results in better performance too, whilst still being able to do precise byte-level protections.

The OS is the only place there is complexity - which has to find a way to fit the mappings the application wants into what the hardware can do (ie. 123456 bytes might become 30 4-kilobyte pages and 576 byte pages.).

replies(6): >>44568880 #>>44569014 #>>44569104 #>>44569119 #>>44569150 #>>44577473 #
ohdeargodno ◴[] No.44569104[source]
Dozens of years of kernel building, dozens of OSes, dozens of physical architectures, all having settled on minimum 4KB pages being a right balance between performance and memory usage, wiped away by a single offhand comment with no knowledge about the situation. Now that's HN.

Just the sheer TLB memory usage and performance implication of doing single byte pages would send CPU performance back to the stone age.

replies(2): >>44569241 #>>44569501 #
FullyFunctional ◴[] No.44569241[source]
Completely false. The 4 KiB page size came from a machine with a total of 512 KiB (1962 Atlas, 3072B pages, 96k 48b words). It hasn’t scaled at all for inertia reasons and it has real and measurable costs. 64 KiB would have been the better choice IMO, but 16 is better than 4.
replies(1): >>44569857 #
1. ohdeargodno ◴[] No.44569857[source]
Hence the "minimum" part. The thread is literally about Android being compiled for 16KB pages, CPU support for larger pages has grown, easily up to 4MB for most consumer CPUs.

Going down _lower_ than 4KB is purely a waste of memory and performance.