On Fri, May 30, 2025 at 9:14 AM Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > > 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: > > 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. Hi Johannes, Thanks! Are you on v1, which lacks folio demotion[1], or v2, which includes it [2]? [1] https://lore.kernel.org/linux-mm/20250412085852.48524-1-21cnbao@xxxxxxxxx/ [2] https://lore.kernel.org/linux-mm/20250514070820.51793-1-21cnbao@xxxxxxxxx/ > > 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. Best Regards Barry
