Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3;
MIME-Version: 1.0
References: <20231121090624.1814733-1-liushixin2@huawei.com>
 <ZVyp5eETLTT0PCYj@tiehlicka> <32fe518a-e962-14ae-badc-719390386db9@huawei.com>
In-Reply-To: <32fe518a-e962-14ae-badc-719390386db9@huawei.com>
From:   Yosry Ahmed <yosryahmed@google.com>
Date:   Tue, 21 Nov 2023 22:44:32 -0800
Message-ID: <CAJD7tkbC=Z6qAE+b6Ch5eVxNY7k0p98i_=RY0m4_3yg5C_zv+A@mail.gmail.com>
Subject: Re: [PATCH v10] mm: vmscan: try to reclaim swapcache pages if no swap space
To:     Liu Shixin <liushixin2@huawei.com>
Cc:     Michal Hocko <mhocko@suse.com>, Yu Zhao <yuzhao@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Huang Ying <ying.huang@intel.com>,
        Sachin Sant <sachinp@linux.ibm.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Kefeng Wang <wangkefeng.wang@huawei.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Nov 21, 2023 at 10:41=E2=80=AFPM Liu Shixin <liushixin2@huawei.com>=
 wrote:
>
>
> On 2023/11/21 21:00, Michal Hocko wrote:
> > On Tue 21-11-23 17:06:24, Liu Shixin wrote:
> >
> > However, in swapcache_only mode, the scan count still increased when sc=
an
> > non-swapcache pages because there are large number of non-swapcache pag=
es
> > and rare swapcache pages in swapcache_only mode, and if the non-swapcac=
he
> > is skipped and do not count, the scan of pages in isolate_lru_folios() =
can
> > eventually lead to hung task, just as Sachin reported [2].
> > I find this paragraph really confusing! I guess what you meant to say i=
s
> > that a real swapcache_only is problematic because it can end up not
> > making any progress, correct?
> This paragraph is going to explain why checking swapcache_only after scan=
 +=3D nr_pages;
> >
> > AFAIU you have addressed that problem by making swapcache_only anon LRU
> > specific, right? That would be certainly more robust as you can still
> > reclaim from file LRUs. I cannot say I like that because swapcache_only
> > is a bit confusing and I do not think we want to grow more special
> > purpose reclaim types. Would it be possible/reasonable to instead put
> > swapcache pages on the file LRU instead?
> It looks like a good idea, but I'm not sure if it's possible. I can try i=
t, is there anything to
> pay attention to?

I think this might be more intrusive than we think. Every time a page
is added to or removed from the swap cache, we will need to move it
between LRUs. All pages on the anon LRU will need to go through the
file LRU before being reclaimed. I think this might be too big of a
change to achieve this patch's goal.

>
> Thanks,
>