From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 C1390433BA6 for ; Mon, 6 Jul 2026 12:54:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783342482; cv=none; b=KQST4e8ZYEYY1ywumavehfAbEnmDq+2it+2F+D3uqNd+Wk+zeyiGg4A3pgwysUZ6YvbkTP9Yaqh8bxc4Eva+aZKrpX0ExxMy1HDwM+XYTboArESuIAwGkHszZHGY/FWCEKJUxcg3sTURpOBhpUFP+ap7cmTXUXyGTqGDqlZT1TE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783342482; c=relaxed/simple; bh=4FjONehcOs2IkCKyliZ0l7h+kt3BmErXegUFbG+1gG4=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GbSkBVBN5gBVdCgnej1cHaEUN9El+pCV96hNdcEJ87FXcCsZtSt3HrHqr5zoKK9fBSeyh0ppxNK54mf0QQ7/bRjPvLrbgzbkivuCt3hgDQmpn3/N5EgefMlOn5dpK/TbCocpgqkEZACuq0YfwjiYZaWRESuvRsqTWBN2z4Oan4Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OVFHaulk; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OVFHaulk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9607A1F0155E for ; Mon, 6 Jul 2026 12:54:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783342481; bh=O5CbBkIap44vv0dv2vbH0BDrSWl7QQVeNrKgD7wP9bs=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=OVFHaulk0NPLBDGMxFVx22h4uhWSI0rSIgJg1MnyJM+e3Fyu94V3W+t6I790kmhGj x05bg1+xSP1gZkpy+epm9XPHf0jWCElNi0gZPPclgFLNlpT6z3aq+nhSx9vIvDRmJ7 VVhdkEzza4n6ZY6qzSVEbJZ2JP1ojVn8bLRg0vjqNbPTDrjZG9qSswWxIvDuwUIboi 02/vNMcrOoCgINQBo+zoyk2eZ4p/To3ZoVhag+kCTAfNV77UZ0gOI4wZJob2l1jH8w POme44tV3Jq7Ls9qX0SwQf5UVOkgBSaONLxbMioExxnzjqR49sPaxn53f0CUTybYld fIFCcaTLTHtgg== Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-92e52c9fddfso129418685a.3 for ; Mon, 06 Jul 2026 05:54:41 -0700 (PDT) X-Forwarded-Encrypted: i=1; AHgh+RoWRmYMeE/P05BygQPXpVM9n6wmcpXmD6sIDwIr6pAlwlLV6/q8Sn3bTo/iErr/2wC5NvPz0lIqTAfjzu4=@vger.kernel.org X-Gm-Message-State: AOJu0YwtKQU+p7P3DTRXbNMJvZWp7X4a8KAmuNtXIlMxyXvFMUEwpQ+4 k8OLOaQTSzbFrwowiO51ZEjCmtRNirswORvvl3Yf7s3bD3c7YA8XBu0K8hruVGqa9ipQZyPub7z aE0OHVFBecx1Wr5CmIDy/EBrx4j+fqQw= X-Received: by 2002:a05:620a:4515:b0:92b:67e6:8ac4 with SMTP id af79cd13be357-92ebb70e907mr53609885a.62.1783342480844; Mon, 06 Jul 2026 05:54:40 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260706081218.3438762-1-richardycc@google.com> In-Reply-To: <20260706081218.3438762-1-richardycc@google.com> From: Barry Song Date: Mon, 6 Jul 2026 20:54:28 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AVVi8CdfHG0hck1UfRCYx5WHJjadHhzP9BH2o_DZBEbKZBrJKijblbNecG1ajMc Message-ID: Subject: Re: [PATCH] mm: vmscan: abort proactive reclaim early when freezing To: Richard Chang Cc: Andrew Morton , Kairui Song , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Lorenzo Stoakes , Suren Baghdasaryan , "T . J . Mercier" , Martin Liu , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 6, 2026 at 4:12=E2=80=AFPM Richard Chang wrote: > > Proactive reclaim (via memory.reclaim or node reclaim) checks for pending > signals in its outer loop in user_proactive_reclaim(). However, the inner > reclaim loops=E2=80=94scanning cgroups in shrink_many() and evicting foli= os in > try_to_shrink_lruvec() can run for a long time before returning to the > outer loop, especially on systems with many cgroups or large memory sizes= . > > This latency in responding to signals can block the freezer (both cgroup > freezer and system suspend), leading to freezer timeouts. This issue was > specifically observed on Android when attempting to freeze background > cgroups while proactive reclaim was active. > > Add a signal_pending() check to should_abort_scan() for proactive reclaim > paths. Since should_abort_scan() is called within the inner scanning and > eviction loops, this allows proactive reclaim to abort early and return t= o > the outer loop, ensuring the task can enter the refrigerator in a timely > manner. > > This check is limited to proactive reclaim (sc->proactive) to avoid > affecting reactive reclaim paths, and wrapped in unlikely() as it is a > slow path. > > Signed-off-by: Richard Chang > --- > mm/vmscan.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 35c3bb15ae96..fb472e924fc7 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -4929,6 +4929,9 @@ static bool should_abort_scan(struct lruvec *lruvec= , struct scan_control *sc) > int i; > enum zone_watermarks mark; > > + if (unlikely(sc->proactive && signal_pending(current))) > + return true; > + Seems reasonable to me. I wonder if you have a script to reproduce the issue. I'd like to test it. Best Regards Barry