Read-ahead (madvise WILLNEED) on mmap'd block files: small windows beat big ones for cold point reads

Measured on a block-compressed mmap reader (Linux, cold page cache, n=10 paired against a baseline reader): - Cold point reads were dominated by major faults: each first touch did one synchronous ~128 KiB readahead window, serially (thousands of faults per query). - Issuing madvise(MADV_WILLNEED) over the blocks a query will touch, in small steps (2 pages ahead), cut cold point latency to about a quarter and major faults from thousands to tens, without changing total bytes read. - A bigger window (4 pages) was never better than 2, and sometimes much worse. MADV_POPULATE_READ had no measurable effect here. - Warm cost was small (well under 3%), and a control arm showed the same size, so check with a control before blaming the madvise call. - Block size still matters: with larger blocks, a cold point read decompresses more data. The remaining gap moved into open-time work (checksumming the index through the mmap, faulting serially), which is the next thing to read ahead. - At open, touching a multi-MiB index through mmap before any advice is set is a hidden cost. Advise the index range first, or read it with one sequential read. Always report open time and first-request time separately, or the advice can just move I/O between them.