On Mon, Nov 27, 2023 at 1:57 PM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > Exactly. Since swap cache has different life time with page cache, they > > would be usually dropped when pages are unmapped(unless they are shared > > with others but anon is usually exclusive private) so I wonder how much > > memory we can save. > > I think the point of this patch is not saving memory, but rather > avoiding an OOM condition that will happen if we have no swap space > left, but some pages left in the swap cache. Of course, the OOM > avoidance will come at the cost of extra work in reclaim to swap those > pages out. You are discussing how to use the memory that got freed. e.g. using other apps so avoid OOM. I am asking how much memory can be freed by this patch. That number is still useful to understand how effective the patch is. Does it justify the additional complexity? > The only case where I think this might be harmful is if there's plenty > of pages to reclaim on the file LRU, and instead we opt to chase down > the few swap cache pages. So perhaps we can add a check to only set > sc->swapcache_only if the number of pages in the swap cache is more > than the number of pages on the file LRU or similar? Just make sure we > don't chase the swapcache pages down if there's plenty to scan on the > file LRU? One idea is that we need to measure how effective the reclaim was toward the swap cache. If we do a lot of work but are not able to reclaim much from the swap cache, then additional reclaim work on swap cache is not going to be effective. MGLRU has a PID controller to adjust the reclaim ratio between the file and anonymous LRU. That is one way of measuring the effectiveness of the reclaim. Use the feedback to adjust the follow up reclaim work. I kind of wish we could have some feedback machine like this for the swap cache reclaim as well. Not sure how complicated it is to implement one. Chris
