4 ms·

> The latency associated with a 2MB or 1GB read/write to disk is just too long to be reasonable. On spinning rust, seek times are O(10ms) and speeds are O(100M

> The latency associated with a 2MB or 1GB read/write to disk is just too long to be reasonable. On spinning rust, seek times are O(10ms) and speeds are O(100MB/s). That means in the time it takes to seek to page in a page, you could read about 1MB worth of data. That should make that order of page size vastly more efficient for paging in data than tiny 4kB pages, from an HDD. From an SSD, sure, the seek penalty is much lower so things should skew in favor of smaller reads.

brandmeyer 6y ago
The seek penalty is lower, true. However, the peak throughput is also much higher, so SSDs share this behavior with HDDs.
jasonwatkinspdx 6y ago
Yeah, that stated rationale is slightly confused. With server class spinning disks, you get something like 90% of sequential bandwidth when doing 8 MiB random reads. There's slight gains up to 32 MiB. So yes, overall bandwidth out of the disk is much better with 2 MiB than 4 KiB. But the question is: how much of that 2 MiB block is actually useful before it gets ejected out of the page cache? For 1 GiB of page cache memory, with 4 KiB pages we get ~260k different entries, but with 2 MiB we only get 512. So we'll end up with a lot of capacity conflicts on the cache unless our workload just happens to only work with a small number of huge memory blocks. That's likely to dominate performance even if we got "free" bandwidth with the large pages. All that said, 4 KiB is a bit painful on modern hardware. Current SSDs are happiest when writes are an integer multiple of around 32 to 64 KiB or so. It'd be nice if we had a medium size pages option.
- my123 6y ago
  On Arm, the possible granule (base page size) sizes are 4KB, 16KB and 64KB. On iOS and macOS on Apple Silicon, the used page size is 16KB across the board. On RHEL/CentOS on Arm64, the used page size is 64KB. In other cases, it's generally 4KB (and is always 4KB on Android or Windows/arm64).

brandmeyer 6y ago

The seek penalty is lower, true. However, the peak throughput is also much higher, so SSDs share this behavior with HDDs.

jasonwatkinspdx 6y ago

Yeah, that stated rationale is slightly confused. With server class spinning disks, you get something like 90% of sequential bandwidth when doing 8 MiB random reads. There's slight gains up to 32 MiB. So yes, overall bandwidth out of the disk is much better with 2 MiB than 4 KiB. But the question is: how much of that 2 MiB block is actually useful before it gets ejected out of the page cache? For 1 GiB of page cache memory, with 4 KiB pages we get ~260k different entries, but with 2 MiB we only get 512. So we'll end up with a lot of capacity conflicts on the cache unless our workload just happens to only work with a small number of huge memory blocks. That's likely to dominate performance even if we got "free" bandwidth with the large pages. All that said, 4 KiB is a bit painful on modern hardware. Current SSDs are happiest when writes are an integer multiple of around 32 to 64 KiB or so. It'd be nice if we had a medium size pages option.

my123 6y ago
On Arm, the possible granule (base page size) sizes are 4KB, 16KB and 64KB. On iOS and macOS on Apple Silicon, the used page size is 16KB across the board. On RHEL/CentOS on Arm64, the used page size is 64KB. In other cases, it's generally 4KB (and is always 4KB on Android or Windows/arm64).