Re: [PATCH v10] mm: vmscan: try to reclaim swapcache pages if no swap space

[Michal Hocko]

On Tue 28-11-23 15:15:08, Minchan Kim wrote:
> On Tue, Nov 28, 2023 at 03:05:29PM -0800, Yosry Ahmed wrote:
> > On Tue, Nov 28, 2023 at 2:45 PM Minchan Kim <minchan@xxxxxxxxxx> wrote:
> > >
> > > On Tue, Nov 28, 2023 at 11:16:04AM +0100, Michal Hocko wrote:
> > > > On Tue 28-11-23 09:31:06, Huang, Ying wrote:
> > > > > Michal Hocko <mhocko@xxxxxxxx> writes:
> > > > [...]
> > > > > > Right. On the other hand we could be more aggressive when dropping the
> > > > > > swapcache. Is there any actual reason why we cannot try to folio_free_swap
> > > > > > even when mem_cgroup_swap_full == F?
> > > > >
> > > > > If there are plenty free space in swap device, why not take advantage of
> > > > > it?
> > > >
> > > > Maybe a stupid question but what is the advantage of keeping around in
> > > > the swap cache?
> > >
> > > If the page is shared, we avoids addtional IO to bring them back so
> > > swap cache.
> > 
> > I think this case is actually necessary for correctness, not just to
> > avoid additional IO. Otherwise subsequent swapins will create new
> > copies of the page, right?
> 
> I think if the page was shared by MAP_SHARED, then, yes.

In that case deleting from the swap cache would fail because there are
still swapped out ptes, no?

> I think if the page was shared by MAP_PRIVATE but CoW(e.g., fork), then, no.

OK, but we are talking about a memory pressure here and evicting
available memory. So what is the actual cost benefit model here?
Is it really better to keep swapcache around even under memory pressure
if the CoWed page could never be faulted in?
-- 
Michal Hocko
SUSE Labs