* Johannes Weiner <hannes@xxxxxxxxxxx> [250529 17:14]: > On Thu, May 29, 2025 at 04:28:46PM +0100, Matthew Wilcox wrote: > > Barry's problem is that we're all nervous about possibly regressing > > performance on some unknown workloads. Just try Barry's proposal, see > > if anyone actually compains or if we're just afraid of our own shadows. > > I actually explained why I think this is a terrible idea. But okay, I > tried the patch anyway. > > This is 'git log' on a hot kernel repo after a large IO stream: Can you clarify this benchmark please? Is this running 'git log', then stream IO, then running 'git log' again? > > VANILLA BARRY > Real time 49.93 ( +0.00%) 60.36 ( +20.48%) > User time 32.10 ( +0.00%) 32.09 ( -0.04%) > System time 14.41 ( +0.00%) 14.64 ( +1.50%) > pgmajfault 9227.00 ( +0.00%) 18390.00 ( +99.30%) > workingset_refault_file 184.00 ( +0.00%) 236899.00 (+127954.05%) > > Clearly we can't generally ignore page cache hits just because the > mmaps() are intermittent. > > The whole point is to cache across processes and their various > apertures into a common, long-lived filesystem space. > > Barry knows something about the relationship between certain processes > and certain files that he could exploit with MADV_COLD-on-exit > semantics. But that's not something the kernel can safely assume. Not > without defeating the page cache for an entire class of file accesses.
