On Tue, 7 Jul 2026 14:25:05 +0800 王翊嘉 <[email protected]> wrote:
> On Sat, Jul 04, 2026 at 08:36:16PM -0700, Andrew Morton wrote: > > I'm not sure this is a good thing for us to be self-testing for. It's > > poking pretty deeply inside the internal implementations of > > kernel-of-the-moment. > > > > Oh well, I guss if the test suddenly starts reporting errors, it might > > be something we want to look into. > > > > Thanks. AI review might have found a couple of things of interest: > > > > https://sashiko.dev/#/patchset/[email protected] > > Thanks for taking a look. > > After thinking more about your concern, I agree that teaching this > selftest how to compute the expected readahead window from sysfs > read_ahead_kb is probably not the right direction. The failure is related > to mmap read-around behaviour, but adding that policy knowledge to the > test makes it depend even more on implementation details. > > The actual failure I was trying to fix is narrower. The existing test > already expects a neighbouring page to become resident after faulting the > middle of the mapping, but it only scans after the faulted page. On the > 64K-page arm64 system where I reproduced this, with the default 128K > read_ahead_kb setting, the file-backed mmap fault on page 32 makes pages > 31 and 32 resident. The original test scans from page 33 onwards, misses > the resident neighbour at page 31, and reports ra_pages == 0. > > I tested a smaller version which drops the readahead_window_pages() > helper and the new skip logic, and only changes the existing check to > scan both sides of the faulted page. On the same 64K-page system, the > original test fails reliably, while that smaller change passes. So the > sysfs/read_ahead_kb logic does not appear to be needed to fix the 64K > failure. > > I am thinking of sending a v4 in that direction: keep the existing > EXPECT_GT(ra_pages, 0) check, but make it count resident neighbouring > pages on both sides of the faulted page, without trying to compute the > expected readahead window in the test. > > The other possible direction is to remove the readahead assertion from > check_file_mmap entirely, similar to the tmpfs case, and only verify that > the faulted page itself becomes resident. That would avoid testing this > implementation detail, but it would also drop the existing coverage. > > Would you prefer one of these approaches? The second approach sounds saner. I'm not sure this test is overall very useful, really. But it's harmless as long as it isn't causing these spurious issues!
