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

[Adam Jackson <ajax@redhat.com>]

On Thu, 2020-03-05 at 16:17 +0100, Michal Hocko wrote:
> On Wed 04-03-20 15:32:35, Adam Jackson wrote:
> > The page reclamation scanner tries to keep executable pages resident,
> > since taking a hard page fault to satisfy an icache miss is really not
> > great for interactivity.  Anonymous executable pages tend to contain
> > code that has been just-in-time compiled for performance reasons. By
> > requiring that executable pages be file-backed, we're putting possibly
> > the most performance-sensitive code at higher risk of eviction, which
> > seems backwards.
> > 
> > On an amd64 machine running Fedora 31, the firefox I happen to have
> > running requires about 89M of file-backed text and 12M of anonymous text
> > for 30 open tabs. The next largest process in terms of anonymous text is
> > gnome-shell, with 1M anonymous and 57M file-backed. No other process had
> > significant anonymous text, most had none. Penalizing those 13M
> > specifically when under memory pressure seems like an easy hazard to
> > avoid.
> 
> Are you seeing an actual improvement from this change? IIRC the primary
> motivation to make this heuristic page cache oriented is that it was
> quite easy to evict file backed memory by streaming IO. This shouldn't
> really be a major problem for the anonymous memory in most cases. A
> heavy swapin/out workload is likely to suffer from not having data
> available more than having the code evicted. But I might be wrong here
> and getting some numbers would be really interesting.

They would be! I confess I don't have any, I'll see if I can gather
some for you. The problem case for this patch is maybe as much about
streaming I/O as it's about just giant wads of dirty data. Given enough
pressure, eventually this loop will prefer to evict jitted code before
precompiled. I find that to be a difficult preference to justify. If
anything maybe you should evict the file-backed code first because you
can discard it instead of writing it out (assuming your swap and
executables are on comparably fast disk, etc).

That's my theory anyway. It's entirely possible I don't understand the
larger environment for this code, and like I say I don't have hard data
yet. For all I know big data-center-y java jobs might actually want the
existing behavior. But it seemed curious enough to warrant at least
sending the patch for feedback.

- ajax