News for hackers. Stuff that matters.
Re:The Linux kernel's inability to gracefully handle low mem... by jdsully on Tuesday August 06, 2019 @01:13AM (#20622333)
Theres no reason extra data cannot be added to entries in the page cache to make smarter decisions. That’s how Windows and OS X do it in their equivalent subsystems.

Nobody is suggesting these pages be pinned which is an extreme measure.

Re:The Linux kernel's inability to gracefully handle low mem... by caf on Tuesday August 06, 2019 @01:58AM (#20622551)
The problem I'm trying to point out here is that if the extra metadata in the page cache is entirely under user control (like for example "is mapped shared" and/or "is mapped executable") then it amounts to a user-specified QOS flag.

That might be OK on a single-user system but it doesn't fly on a multi-user one. That's why I suggested you could gate that kind of thing behind some kind of superuser control.

Re:The Linux kernel's inability to gracefully handle low mem... by jdsully on Tuesday August 06, 2019 @03:45AM (#20623083)
Why can’t a user make QoS decisions for their own pages? Root controlled pages should obviously have higher priority.

The kernel could still “fairly” evict pages across users - just letting them choose which N pages they prefer to go first.

Re:The Linux kernel's inability to gracefully handle low mem... by caf on Tuesday August 06, 2019 @04:03AM (#20623184)
Why can’t a user make QoS decisions for their own pages?

Because then you just get everyone asking for maximum QOS / don't-page-me-out on everything they can.

The pages in the page cache are not owned by a particular user, they're shared. If there's three users running /usr/bin/firefox, they'll all have have shared read-only executable mappings of the same page cache pages. If you do a buffered read of a file immediately after I do the same, we both get our data copied from the same page cache page. So it's not at all clear how you'd do the accounting on this to implement that user-based fairness criterion.