I wonder if a possible solution would be to limit how fast
file pages get reclaimed, when the page cache is very small.
Say, inactive_file * active_file< 2 * zone->pages_high ?
Why do you multiply inactive_file and active_file?
What's meaning?
I think it's very difficult to fix _a_ threshold.
At least, user have to set it with proper value to use the feature.
Anyway, we need default value. It needs some experiments in desktop
and embedded.
At that point, maybe we could slow down the reclaiming of
page cache pages to be significantly slower than they can
be refilled by the disk. Maybe 100 pages a second - that
can be refilled even by an actual spinning metal disk
without even the use of readahead.
That can be rounded up to one batch of SWAP_CLUSTER_MAX
file pages every 1/4 second, when the number of page cache
pages is very low.
How about reducing scanning window size?
I think it could approximate the idea.
Would there be any downsides to this approach?
At first feeling, I have a concern unbalance aging of anon/file.
But I think it's no problem. It a result user want. User want to
protect file-backed page(ex, code page) so many anon swapout is
natural result to go on the system. If the system has no swap, we have
no choice except OOM.