From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from out-186.mta0.migadu.com (out-186.mta0.migadu.com [91.218.175.186])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5478C44A71D
	for <linux-kernel@vger.kernel.org>; Wed,  8 Jul 2026 16:51:22 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.186
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1783529491; cv=none; b=fLXZH/axzsWFxL57hYg3OTQ+qRSo33ZbUtFOrLgqOilneHVAbJwrrE4doL8EArqSK+p4q0Frduyo0+dD3gqU31TDTX/+r2lOMJekb3kh3GWvKEy4dY0S9dRGqXkTvIDVcsBQGFzhhoNWxGSNgy1ZatZ/xdaExDXs79n4fF3bOHs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1783529491; c=relaxed/simple;
	bh=cTNwazgNqnhm/KVmjrEsLSOMhHB+0p+BBgsKeHn7wgU=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=Ujjpk6HCGzXDYqNRvDpCBW4455gU61Wc7mHR9phl5SOKpFupClNa7YsRNwbvcdKn1mMSjhhawYKz7Ld6SJBTNyKOGzsR6JixdaGM0/agEJlE4OBYg03UDl4e1zl3UajR7SckqjgNAMlylVlw9VfaA1VAk1ZiRMpc7P8QhKFdLY0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=hYG4YQKG; arc=none smtp.client-ip=91.218.175.186
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="hYG4YQKG"
Date: Wed, 8 Jul 2026 09:51:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;
	t=1783529476;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=ucWwaSFjCVK5PpHi7O84rrG1/RwptI0feQpEp5dgE6k=;
	b=hYG4YQKGDkKYH3KblcwWJAOclqY5v0R+9bl8qfSPdt/Wi1r2BfI+v032SK+xtmgm9Q0etI
	1Xc0nwe57wqCsCChmvrPmdiUYGuQRGnt4ncH/nl0h+0/pE7WQVaMhAta9f4LsIWtSr1UqY
	IQjUSLs6MHcHlFUFkhxZjHeOKDEjXl8=
X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers.
From: Shakeel Butt <shakeel.butt@linux.dev>
To: "T.J. Mercier" <tjmercier@google.com>
Cc: Richard Chang <richardycc@google.com>, 
	Andrew Morton <akpm@linux-foundation.org>, Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>, 
	Barry Song <baohua@kernel.org>, Axel Rasmussen <axelrasmussen@google.com>, 
	Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>, 
	Johannes Weiner <hannes@cmpxchg.org>, David Hildenbrand <david@kernel.org>, 
	Michal Hocko <mhocko@kernel.org>, Lorenzo Stoakes <ljs@kernel.org>, 
	Suren Baghdasaryan <surenb@google.com>, Martin Liu <liumartin@google.com>, 
	Minchan Kim <minchan@kernel.org>, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing
Message-ID: <ak5-qwmpXrYi5md6@linux.dev>
References: <20260706081218.3438762-1-richardycc@google.com>
 <ak1XzPxbwBF72d1m@linux.dev>
 <CALC_0q9=KNnkQBE_7gC60jZ2Akj9jgL+VaDMFd7yGvqyfTJbYw@mail.gmail.com>
 <ak3Xtrtm5iVayEx7@linux.dev>
 <CALC_0q-juSkv=iqG7mAGCuGqbdCtjEHEy6oD1pcxQkFdBMJHWg@mail.gmail.com>
 <ak5wxwj8cID-QQCF@linux.dev>
 <CABdmKX2C-XPN7Z3G7joSHUxhzEmp5dgNf_oA_ojQ_coM_CmvPQ@mail.gmail.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABdmKX2C-XPN7Z3G7joSHUxhzEmp5dgNf_oA_ojQ_coM_CmvPQ@mail.gmail.com>
X-Migadu-Flow: FLOW_OUT

On Wed, Jul 08, 2026 at 09:03:17AM -0700, T.J. Mercier wrote:
> On Wed, Jul 8, 2026 at 8:48 AM Shakeel Butt <shakeel.butt@linux.dev> wrote:
> >
> > On Wed, Jul 08, 2026 at 03:24:15PM +0800, Richard Chang wrote:
> > > On Wed, Jul 8, 2026 at 12:54 PM Shakeel Butt <shakeel.butt@linux.dev> wrote:
> > > >
> > > > What's so special about proactive reclaim? Why the same situation can not happen
> > > > for global or memcg reclaim?
> > > >
> > >
> > > The target batch size of the global/memcg reclaim is typically very
> > > small -- usually SWAP_CLUSTER_MAX (32 pages), allowing the task to
> > > yield or check signals between attempts.
> > > Furthermore, kswapd is a kernel thread designed to be freezable, it
> > > explicitly checks kthread_freezable_should_stop() in the main loop.
> > > In contrast, the target batch size in proactive reclaim is
> > > user-defined and can be extremely large. Without signal checks in the
> > > inner loops, the task may continue scanning and evicting pages for
> > > seconds at a time.
> >
> > Why can't the proactive reclaim use the same batch size as memcg and global
> > reclaim?
> 
> Because it is very slow:
> https://lore.kernel.org/all/20240202233855.1236422-1-tjmercier@google.com/

Yes, we should fix reclaim and preferrably have single solution for all types of
reclaim. Though that is orthogonal and out of scope for this patch.

The reason behind my questioning is that the commit message should have all of
this information from the start instead of requiring readers to extract all of
this.