undefined
@EricLasota The best you can probably do is give the kernel as much info as possible about which pieces of memory have the least bad effect when evicted (i.e. memory priorities), because the kernel is in a position to actually make meaningful decisions on what to evict.
Of course that doesn't replace app-side freeing of resources on memory contention, but I'm doubtful a kernel-side notif would be less racy/broken than e.g. detecting memory contention based on sampling total mem usage.
@EricLasota Well, as long as the total memory usage is below physical memory size, there is nothing to evict in any case.
On the problem of apps not recovering from persistent evictions, there's just not much that apps can do here. As long as there is memory contention, the kernel may have to evict "random" memory at "random" times. For every form of notification the kernel may provide, there is a case where apps acting on that notification does nothing at best and is harmful at worst.
@EricLasota I'd argue such a number does not exist in any useful capacity, and the real mistake was pretending that it does. The kernel might evict buffers at pretty much any time, and processes can get preempted more or less at random, so any reported "safe capacity" is going to be completely useless because by the time your code gets to make any decisions based on the number, other processes could run which may completely change the circumstances the original capacity was determined under.