Received-SPF: pass (google.com: domain of linux-kernel+bounces-55823-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240131-async-free-v2-1-525f03e07184@kernel.org>
 <87sf2ceoks.fsf@yhuang6-desk2.ccr.corp.intel.com> <7f19b4d69ff20efe8260a174c7866b4819532b1f.camel@linux.intel.com>
 <CAF8kJuNvB8gXv3kj2nkN5j2ny0ZjJoVEdkeDDWSuWxySkKE=1g@mail.gmail.com>
 <1fa1da19b0b929efec46bd02a6fc358fef1b9c42.camel@linux.intel.com>
 <CAF8kJuMz+HCHkPUQhum32EPB7E1uVvN-E-TffOS7SSHxJNwNmQ@mail.gmail.com> <a869aff64f69bd1e1318653559f4c32e9f0a4c08.camel@linux.intel.com>
In-Reply-To: <a869aff64f69bd1e1318653559f4c32e9f0a4c08.camel@linux.intel.com>
From: Chris Li <chrisl@kernel.org>
Date: Tue, 6 Feb 2024 17:51:19 -0800
Message-ID: <CAF8kJuNC1D0sy90GoSt6yiA7T0Htsu_-gXsbTkmK5GAdO4udgA@mail.gmail.com>
Subject: Re: [PATCH v2] mm: swap: async free swap slot cache entries
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: "Huang, Ying" <ying.huang@intel.com>, Andrew Morton <akpm@linux-foundation.org>, 
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, 
	=?UTF-8?B?V2VpIFh177+8?= <weixugc@google.com>, 
	=?UTF-8?B?WXUgWmhhb++/vA==?= <yuzhao@google.com>, 
	Greg Thelen <gthelen@google.com>, Chun-Tse Shao <ctshao@google.com>, 
	=?UTF-8?Q?Suren_Baghdasaryan=EF=BF=BC?= <surenb@google.com>, 
	=?UTF-8?B?WW9zcnkgQWhtZWTvv7w=?= <yosryahmed@google.com>, 
	Brain Geffon <bgeffon@google.com>, Minchan Kim <minchan@kernel.org>, Michal Hocko <mhocko@suse.com>, 
	Mel Gorman <mgorman@techsingularity.net>, Nhat Pham <nphamcs@gmail.com>, 
	Johannes Weiner <hannes@cmpxchg.org>, Kairui Song <kasong@tencent.com>, 
	Zhongkun He <hezhongkun.hzk@bytedance.com>, Kemeng Shi <shikemeng@huaweicloud.com>, 
	Barry Song <v-songbaohua@oppo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 6, 2024 at 5:08=E2=80=AFPM Tim Chen <tim.c.chen@linux.intel.com=
> wrote:
>
> On Mon, 2024-02-05 at 11:10 -0800, Chris Li wrote:
> >
> >
> > In our system, a really heavy swap load is rare and it means something
> > is already wrong. At that point the app's SLO is likely at risk,
> > regardless of long tail swap latency. It is already too late to
> > address it at the swap fault end. We need to address the source of the
> > problem which is swapping out too much.
> >
> >
>
> Could some usage scenarios put more pressure on swap than your
> usage scenario?  Say system with limited RAM and rely on zswap?
>
Of course. In that case what I proposed  to do will already doing what
I think is the best of this situation. After grabbing the cache lock
and finding out async fre hasn't started the freeing yet. Just free
all 64 entries in the swap slot cache. It is similar to the old code
behavior.
Yes, it will have the long tail latency due to batch freeing 64 entries.
My point is not that I don't care about heavy swap behavior.
My point is that the app will suffer from the swap strom anyway, it is
unavoidable. That will be the dominant factor shadowing the batch free
optimization effect.

Or do I miss your point as you want to purpose the swap cache double
buffer  so it can perform better under swap storm situations?

Chris