Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
MIME-Version: 1.0
References: <20231121090624.1814733-1-liushixin2@huawei.com>
 <ZVyp5eETLTT0PCYj@tiehlicka> <32fe518a-e962-14ae-badc-719390386db9@huawei.com>
 <CAJD7tkbC=Z6qAE+b6Ch5eVxNY7k0p98i_=RY0m4_3yg5C_zv+A@mail.gmail.com>
 <ZV3BWZ4ZaD5Rj_HS@tiehlicka> <ZV3TQCElHpcp0h0V@tiehlicka> <CAJD7tka0=JR1s0OzQ0+H8ksFhvB2aBHXx_2-hVc97Enah9DqGQ@mail.gmail.com>
 <ZV3_6UH28KMt0ZDb@tiehlicka> <87msv58068.fsf@yhuang6-desk2.ccr.corp.intel.com>
 <ZWDPuR5Ssx07nBHb@tiehlicka> <87h6l77wl5.fsf@yhuang6-desk2.ccr.corp.intel.com>
In-Reply-To: <87h6l77wl5.fsf@yhuang6-desk2.ccr.corp.intel.com>
From:   Chris Li <chrisl@kernel.org>
Date:   Sun, 26 Nov 2023 23:42:11 -0800
Message-ID: <CAF8kJuOcMDpqZV+9+QjK-hsoJLGhoBzBOczAc7+UMypVJresSw@mail.gmail.com>
Subject: Re: [PATCH v10] mm: vmscan: try to reclaim swapcache pages if no swap space
To:     "Huang, Ying" <ying.huang@intel.com>
Cc:     Michal Hocko <mhocko@suse.com>,
        Yosry Ahmed <yosryahmed@google.com>,
        Liu Shixin <liushixin2@huawei.com>,
        Yu Zhao <yuzhao@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        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

Hi Ying,

On Sun, Nov 26, 2023 at 6:36=E2=80=AFPM Huang, Ying <ying.huang@intel.com> =
wrote:
>
> Michal Hocko <mhocko@suse.com> writes:
>
> > On Thu 23-11-23 14:15:59, Huang, Ying wrote:
> >> Michal Hocko <mhocko@suse.com> writes:
> > [...]
> >> > Yes swapcache pages are indeed more complicated but most of the time
> >> > they just go away as well, no?
> >>
> >> When we swapin a page, we will put it in swapcache too.  And the page
> >> can be in that state for long time if there is more than 50% free spac=
e
> >> in the swap device.
> >
> > True, but why is that a problem? If you encounter such a swapped in pag=
e
> > on the file LRU then the page should be referened and as such should be
> > activated, no?
>
> This just means that anonymous pages in file LRU aren't temporary or
> short-term.  So we need to consider that.  For example, the original
> method to balance between anonymous pages and file pages need to be
> re-designed.  The anonymous pages are considered hotter than file pages
> in general.

 I agree with Ying that anonymous pages typically have different page
access patterns than file pages, so we might want to treat them
differently to reclaim them effectively.
One random idea:
How about we put the anonymous page in a swap cache in a different LRU
than the rest of the anonymous pages. Then shrinking against those
pages in the swap cache would be more effective.Instead of having
[anon, file] LRU, now we have [anon not in swap cache, anon in swap
cache, file] LRU

Chris