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
