memory_pages evicts mapped pages, which gives back no anonymous memory and costs a pread

[tamnd]

memory_pages is a promise about anonymous bytes. Once #757's map_settled is on, a settled page is a mapping of the file, and a mapping costs no anonymous bytes at all. Evicting one therefore gives back nothing the kernel was not already free to take, and it buys a pread on the next read of that page. The bound is doing work against itself.

2e61a2b fixed the worst version of this, which was an ordering accident: evict_settled ran the remap before the eviction, so on a bulk load, where the flusher settles pages in bursts and a whole burst lands below the floor at once, every settled page was mapped by one half of the call and unmapped by the other half of the same call. Two syscalls a page for a mapping that never served a read.

What that fix does not touch is the steady state. The floor sits at tail - memory_pages and the read-only boundary sits at tail - mutable_pages, so there is a band of memory_pages - mutable_pages pages between them where a page is settled and still above the floor. Every page transits that band as the log grows. So on a sustained write with both options set, each page is still mapped once and unmapped once, and with a tight bound the band is a page or two wide and the mapping's whole life is the time the tail takes to move two pages. That is churn with a real cost and no benefit.

The shape of the answer looks like this, and it needs deciding rather than guessing:

• memory_pages counts anonymous pages only, and a mapped page is out of scope for it. evict_behind would skip a mapped victim instead of unmapping it, which means head has to be able to move past a page whose slot is still populated. Today everything below head is assumed not resident, so this is not a one line change and the invariant needs restating first.
• Or the two options are declared mutually exclusive, Options::validate refuses a database with both set, and the documentation says a mapped tail is the bound. That is honest and cheap and it gives up the case where somebody wants a hard ceiling on total resident bytes and not just anonymous ones.
• Or eviction unmaps but only under memory pressure it can observe, which is the virtual memory assisted buffer management direction from Leis and colleagues (SIGMOD 2023) and is a much larger piece of work.

There is a measurement that decides which of the first two is right, and it is not taken yet: whether a mapped read that faults is cheaper or dearer than the pread it replaces. That is the #757 A/B, queued on server3. If the mapping wins, the bound should stop evicting mapped pages and the first option is worth its cost. If the mapping loses, map_settled is not becoming the default anyway and the second option costs nothing.

So this is blocked on #757's numbers and should not be picked up before them. Filing it now because the interaction is live in the code today for anybody who sets both options, and the only thing standing between a user and the churn is that map_settled defaults to off.

[tamnd]

Implemented at 67d52e7 on zu2-planes, and the invariant question this was blocked on turned out to be smaller than the issue said.

The worry was that head means "everything below this is not resident", so a floor that walks past a page still in memory breaks something. It does not, and the engine says so itself. Log::resident carries this comment already:

The head boundary is deliberately not consulted. It can move while a session is mid-operation; the page pointer cannot become dangling until that session's epoch has passed, so the pointer is the honest test and the boundary is not.

Nothing outside log.rs reads head at all. Inside it there are four uses: the eviction loop, which is what this changes, remap_settled's start hint, which is a cursor that only goes up, and the two fetch_max calls in reclaim_to and resume_at, which push the floor up to a compaction boundary. Those two are about addresses that have become unreachable rather than merely cold, and the pages under them are nulled out in the same call. So the floor already said who is responsible for a page and not whether it is resident, and the module header was the only place claiming otherwise. That comment is now corrected rather than the code.

What landed:

• memory_pages is a count of anonymous pages, kept as a counter on the log rather than as a walk of the page table, because the eviction loop asks on every page it considers. It moves in three places: a page published by ensure_page or warm_page comes in, and release_page is the one door out.
• evict_behind steps over a mapped victim, moving the floor past it while the page stays where it is. The loop also stops at the page being appended to, so a run of mapped pages cannot walk the floor up to the tail when there is no anonymous page left to give.
• evict_settled now maps before it evicts, the other way round from Every resident page is anonymous memory, so zu2 holds 65x more of it than lmdb and the kernel cannot reclaim any of it #757. That order was chosen while a mapped page still counted against the bound, so the two halves of one call undid each other. They cannot now, and a settled page should be offered the cheaper of the two ways out of anonymous memory first.
• zu2_anonymous_pages on the C API. The ycsb driver was working the figure out as resident minus mapped, which is two page table walks taken a moment apart, and when it lost that race it printed 1.8e13 MiB. One counter, one load. The clamp added for it is gone.

With mapping off nothing changes: every resident page is anonymous, so the count and the old distance rule agree.

Test at a_mapped_page_is_outside_the_memory_bound in end_to_end.rs: 20000 records of 8 KiB against a bound of four pages, and it asserts both halves, that the resident set goes well past the bound and that the anonymous count stays inside it, then reads every key back rather than a sample, because a resident page below the eviction floor is the new thing here. Full suite clean, clippy clean.

Not measured yet. The A/B on server3 is queued behind a sqlite E retake and now has four arms rather than two: unbounded heap, unbounded mapped, bounded heap, bounded mapped. The last is the one this issue is about, and the bound is five pages, 20 MiB, the rung that gave 25742 ops against sqlite's 3544 in #636.

[tamnd]

A data point for the churn, from putting map_settled through
tests/racy.rs for the first time in a44b5e5. Four writers, an evictor
and a compactor over a log that laps, on a laptop, so this is a shape
and not a benchmark number.

Db::remap_made is new and counts mappings published, which is what
this needed: mapped_pages is a gauge and it reads zero at the end of
any run long enough for the last compaction to take the pages back, so
it cannot say whether map_settled did anything at all. I got that
wrong first time round and concluded from a gauge of zero that a page
bound suppressed mapping entirely. It does not.

At four hundred thousand operations a thread:

memory_pages	mappings made	gauge at rest
8 of 16 pages	142	0
unbounded	150	0

So on this shape the bound is not what drives the churn, the compaction
is. Both arms map and unmap about the same number of pages, and the
mapping's life is bounded by the pass that reclaims the page rather than
by the band between the floor and the read-only boundary that this issue
describes. That does not contradict the analysis here, it adds a second
source of churn that a mutual exclusion between the two options would
not fix.

Still blocked on #757's numbers for the decision, and that run is still
queued on server3 behind a rival benchmark.