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

[Adam Jackson <ajax@redhat.com>]

On Thu, 2020-03-05 at 12:41 -0800, Shakeel Butt wrote:

> Have you actually seen this issue (i.e. JIT code reclaimed and
> thrashing) happening for real workloads?

The mention of gnome-shell wasn't entirely an accident, it's largely
written in javascript which is jit-compiled. Under sufficiently dire
disk I/O conditions merely moving the cursor would lag. That ought to
be impossible, because nothing in the cursor update path ought to be
blocking on the disk and we believe the CPU scheduler to be competent.
Plenty of bugs are contributing here, but among them yes the (jitted
bits of the) cursor update code can get paged out while megabytes of
file-backed text stay resident. It's certainly drowned out by the
contribution of the plenty of other bugs involved, but still.

> 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.

- ajax