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 C1D54433BB8 for ; Tue, 7 Jul 2026 18:28:42 +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=1783448923; cv=none; b=jxke5c7aakRP+3wUQECEnepwWxvBX/iVVACbcyhbXHSOhtVAzOIgtmREeDFfdaIT8qngYn0AYhxKiZeUbjN27K7rwUlX8fIbXUEHg9qm2DiJv52sTZUhO1daKr9oECEZIPxX+mF/hJ2MJKLCo/T1f9NRYDYuhtOaGWh5YTqTCGY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783448923; c=relaxed/simple; bh=0dH8JAh1G57HMXaVWGg//6vzyB5YjbMb2cp9YI+w6Tk=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZqXvuSJdAv+R6WowV/2JYN+JQWTPMbSm5M2U7PVFihYZ4fyjNWL2G0CaD5gXD9ggjC5Phxx46iDbyE8Kp6RyakR84Sj575LJCoW2CMk1oMPXb4VJ4o9mDIP893IEkdqONDYGA4lc22yXXoM7MVGVfQVxtpTyKGNQC3WyQ0YLoz4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NFGJ6LFw; 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="NFGJ6LFw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7B131F01558 for ; Tue, 7 Jul 2026 18:28:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783448922; bh=0dH8JAh1G57HMXaVWGg//6vzyB5YjbMb2cp9YI+w6Tk=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=NFGJ6LFwMM0wniwHQRAFhpZcxkzXXZ+go5O3i2PpdW0RgRJSN8TdzgkZqSUvQQJwF MQmwUJb/vut4/QI97wjiJEf7sZvAQmdV7Rgd4epLjc+1snU2BouoclzM/0do2pntnU h/Am3/IAufzyAMNG73/Fc+iqb18RprupfmBdVicN+byvPY8mt4FOBzdfVWPi1VR3xW 1qdaOLfmatCRCbm6rQ9zDIcBCgbA67cemDG4HPpZ6ibwYF0nQ9ybUbg64Rp5BZnf/U SHtdhRBDaiJB7AHMCD6GpTms0Lr9ec78ID/sVzYlYjFaguzd4xG5Cyb6wp4lQfILPt IdZzN2HypcjwA== Received: by mail-ed1-f50.google.com with SMTP id 4fb4d7f45d1cf-691c5776f95so8458049a12.3 for ; Tue, 07 Jul 2026 11:28:42 -0700 (PDT) X-Forwarded-Encrypted: i=1; AHgh+RrRMepjx2fAqGF0vZniHxGW/6OKaxNDk782L4tbIA2eQeT1lS84Hr9iSa6InXKJXB9VDFWnFBcJUua4vos=@vger.kernel.org X-Gm-Message-State: AOJu0YxRdHURo6Qayt7XtsQxVjM/GKqPSm2f7SgH2nG8zGQVNdc+v557 QCQnO/UUjJlxie31SLn5DhQs0/Q6pbr+E1m/z7pVNq3R1/iFtuafgTDlLTp1y5Lu+m1HNHtGh9Z f/exN/HKUTS24w6gYa4Grv/qpXo5X/rI= X-Received: by 2002:a17:907:25c5:b0:c12:7f26:a279 with SMTP id a640c23a62f3a-c15a680d0bbmr487638466b.23.1783448921599; Tue, 07 Jul 2026 11:28:41 -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: From: Yosry Ahmed Date: Tue, 7 Jul 2026 11:28:29 -0700 X-Gmail-Original-Message-ID: X-Gm-Features: AVVi8CcB1qCEDIvapMeK1t0hPshctDu160D2ocIJ-xaWRXpuClIlmKOhMx9VWwg 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 , Barry Song , 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 Tue, Jul 7, 2026 at 10:20=E2=80=AFAM Yosry Ahmed wr= ote: > > > > On Mon, Jul 06, 2026 at 08:12:18AM +0000, Richard Chang wrote: > > > Proactive reclaim (via memory.reclaim or node reclaim) checks for pen= ding > > > signals in its outer loop in user_proactive_reclaim(). However, the i= nner > > > reclaim loops=E2=80=94scanning cgroups in shrink_many() and evicting = folios in > > > try_to_shrink_lruvec() can run for a long time before returning to th= e > > > outer loop, especially on systems with many cgroups or large memory s= izes. > > > > > > This latency in responding to signals can block the freezer (both cgr= oup > > > 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 rec= laim > > > paths. Since should_abort_scan() is called within the inner scanning = and > > > eviction loops, this allows proactive reclaim to abort early and retu= rn to > > > the outer loop, ensuring the task can enter the refrigerator in a tim= ely > > > manner. > > > > Do we still need the check in the outer loop? > > I believe we still need the outer loop check. Otherwise, we will waste > CPU cycles entering the inner loop only to bail out. (Moving your reply after the relevant text, please avoid top-posting: https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying). My question was whether or not it matters in practice, sure we'll waste some cycles but I don't think it would ultimately matter. That being said, seems like this change only covers MGLRU, so we still need the outer check at least for classic LRU.