Re: [PATCH] mm/vmscan: Prioritize anonymous executable pages like we do file-backed

[Mel Gorman <mgorman@techsingularity.net>]

On Thu, Mar 05, 2020 at 05:58:59PM -0500, Adam Jackson wrote:
> > Originally this heuristic was added to protect executable file pages
> > from the streaming workloads. Now we have workingset detection for
> > file pages and there is ongoing work for adding that support for anon
> > pages, I am wondering if this specific heuristic is still helpful.
> 
> Enh. I would tend to think that code is way more precious than data in
> terms of staying resident. If the working set detection works well
> enough to come to that conclusion on its own without explictly knowing
> about executable pages, that'd be awesome and I'd be entirely fine with
> removing even more of this heuristic.
> 

Given the increased use of JIT engines, the existence of working set
detection and the fact it may also work for anonymous pages soon, I
think it's worth at least *trying* to remove the heuristic in case it
stays around for years as magic code.

Creating an automated test case for this would be relatively tricky. Could
you put together a debugging patch that simply counts some events to put
into the changelog? The events (which could be vmstat) would be

o VM_EXEC pages encountered in reclaim
o Number exec file-backed pages preserved
o Number exec anon pages preserved
o Number exec file-backed pages reclaimed
o NUmber exec anon pages reclaimed

And show the figures before and after in the changelog running Firefox
with excessive IO in the background. It's a bit of legwork but it's to
preserve in the changelog that this problem definitely happens and the
patch has a positive impact. Some comment saying the cursor is not laggy
with the patch applied would also be a plus. The debugging patch would
not actually be merged.

With the figures, if there ever is a bug report that bisects to this patch,
it'll be known exactly what the impact and motivation was. That will at
least make people pause and think before blindly reverting it.

I'm guessing the impact is that the ratio of reclaimed/preserved for anon
pages is currently skewed and after the patch it's more in line with the
ratio for file-backed. It's a tough prediction as the size of the file
vs anon LRUs at the time of reclaim matter as well as the ordering of
pages in the LRU.

-- 
Mel Gorman
SUSE Labs