Skip to content

Handle larger OS page sizes in VM eviction#527

Draft
adsharma wants to merge 1 commit into
mainfrom
ladybug-page-size
Draft

Handle larger OS page sizes in VM eviction#527
adsharma wants to merge 1 commit into
mainfrom
ladybug-page-size

Conversation

@adsharma
Copy link
Copy Markdown
Contributor

Fixes #526.

Summary

This changes VM eviction to distinguish Ladybug logical frame size from the operating system discard granularity. A build with 4 KiB database pages can run on a kernel with a larger page size, such as 16 KiB, without calling madvise on a non-OS-page-aligned 4 KiB frame.

VMRegion now detects the runtime OS page size and tracks resident logical frames per discard granule. The buffer manager charges the granule size only when the first logical frame in that granule becomes resident, and frees it only when the last logical frame in the granule is evicted.

Root cause

The old VM region layout addressed frames as region + frameIdx * LBUG_PAGE_SIZE and evicted each frame with madvise(frame, LBUG_PAGE_SIZE, MADV_DONTNEED). On a 16 KiB kernel page system, only every fourth 4 KiB frame begins on an OS page boundary, so madvise can fail for the other frames.

Aligning the madvise range outward would be unsafe because the surrounding 16 KiB OS page can contain neighboring logical frames that are still resident or dirty. This change waits until all logical frames in the discard granule are evicted before releasing the underlying OS page.

@adsharma
Copy link
Copy Markdown
Contributor Author

Too risky for the 0.17.0 release. Let's get this in after the release goes out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Buffer manager crashes on kernels with CONFIG_PAGE_SIZE_16KB=y (e.g., Raspberry Pi 5 aarch64)

1 participant