From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f202.google.com (mail-pf1-f202.google.com [209.85.210.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FF6637D128 for ; Thu, 9 Jul 2026 07:23:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783581801; cv=none; b=frZGFP5X2NC4mhAADYjbuzdnt2d6k3zKmq1lNfpu/lRlaPr4Hq4gVNAgJP20kNR7CEzI1CCQkEtTYBOM/savw87PzB0xWcNBV1sL+QqjMn9ettbWoqqdIRr28dy+53JEEA3kztYH0di+jTDxzt0pHS7rrgyTQedDJ0U2mjU5Rl0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783581801; c=relaxed/simple; bh=vmOySDlFJRJfRQMrDmNc6KpHXKuyLN6lxqlOCx+xqSo=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=EUNaKhG1v/CdikYL++Q8jP0Be2vTwJAQQUldkmkU3mKMnU3eMlh0J+u2TO6INFkc+c2zK4JpczOm9apCs9RltgSIN3B+loe77wu4zklm7I3NdN1Lt3AVH4czlKqS76SE7RU/6jEHIYK5g5nK8VQL9igOEdGRi5jVF5SEZ/nwiCw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--richardycc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Iu9a93pd; arc=none smtp.client-ip=209.85.210.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--richardycc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Iu9a93pd" Received: by mail-pf1-f202.google.com with SMTP id d2e1a72fcca58-8423f544944so1545508b3a.3 for ; Thu, 09 Jul 2026 00:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783581800; x=1784186600; darn=vger.kernel.org; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=1TSgsShlAlS/YHIH2eE10SQokZv8lmk2KYUHn6cAnAI=; b=Iu9a93pdvtZh0AES9DiOJzpyjH/NFR1O75iGW4jOPknppPLyIqOFOB4GOq3/4NSDKH TZIff4viJkhsHFnHIfFeNbsSNk4OcKJSa8buFZ5GW1OUp0100BNN94AOWNsqiNTKyzo/ m+Hjd9OXEYThAX1MXS4X/Hl8Xp+Szu+SecWY4rB0zXVsA9YIXh3Dp8BYxPxpDwLeVPL6 mP97Hui88zpsKHDTLMHmBvRp2M8LIV0AgBJuJTdlTtYtJsFufwy6tT7iGOcWx8TilgJY hKQWP9JgkEMrQSvZfoAnXVM86Ldd/d2WzOkr252KtX1EzQWyVDGrNgoTjMEGWooQN3V/ yezg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783581800; x=1784186600; h=content-transfer-encoding:content-type:cc:to:from:subject :message-id:references:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1TSgsShlAlS/YHIH2eE10SQokZv8lmk2KYUHn6cAnAI=; b=l/BcmNwfiwhew0wLgg6DRed5RIbpB5hyI0axzNjyfgzk/xp/rFNxi9wkPhSpCPNV+n 2qfXJvhJzq/00w4xFGSH78c4yCGu7RMY7no15JEvfyM6jVfga96+yvR1mYxLbnj6qTjS EPUkvURVdO2mrqXL66jAWDFHt73q+HjoYJhAHfX/6vXDV6vjBIp8pQESvsN2HB5orW0e MGyTmQ0nMUzF+d2ooTcDEh3vLY2wBmNlei6pmt68h8Bzw3i67hDVTlZGmyjCHv7GJ15+ ZDTN01DuRVpag1k3/TtONMed2XOYqXzW83+IjvS8/5goXcJsxFSVoRGdeoQG2djEG/q8 Cweg== X-Forwarded-Encrypted: i=1; AHgh+RogRKpH2AAKR6kYA0hIeAj7O4hUOZ9MyIe8f7UkrTBlC0E95Gh5tefo36wygSDkelRrGdmeShSuM66pbc8=@vger.kernel.org X-Gm-Message-State: AOJu0Yyr1beLlsZMxn/tvNaNHgiByoj2fFZVGLOmVV1J/1r1lfawbYyq ta8xTvWTl0vlVAs9LCi3DLy8S+iUQcZOouGQ1zTQ+WmGs+Hr0ge3w7UXHi0AlbVBb3HKrBg6tXX yAYpPQZ+qOZfo3bmAs9vu X-Received: from pfblj3.prod.google.com ([2002:a05:6a00:71c3:b0:848:50ed:208e]) (user=richardycc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a00:748a:b0:848:469d:b7b2 with SMTP id d2e1a72fcca58-848469dbc0dmr4324674b3a.77.1783581799210; Thu, 09 Jul 2026 00:23:19 -0700 (PDT) Date: Thu, 9 Jul 2026 07:22:31 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: X-Mailer: git-send-email 2.55.0.795.g602f6c329a-goog Message-ID: <20260709072231.3163082-1-richardycc@google.com> Subject: [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend From: Richard Chang To: Andrew Morton , Kairui Song , Qi Zheng , Shakeel Butt , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Lorenzo Stoakes Cc: Suren Baghdasaryan , "T . J . Mercier" , Martin Liu , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Richard Chang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Proactive reclaim (triggered via memory.reclaim or node sysfs) checks for pending signals in its outer loop in user_proactive_reclaim(). However, the inner reclaim loops=E2=80=94specifically scanning cgroups in shrink_many() and evicting/aging folios in try_to_shrink_lruvec()=E2=80=94can run for a long time before returning to the outer loop, especially on systems with many cgroups or large memory sizes. During system suspend, the PM freezer attempts to freeze all the tasks by sending signals. Because the inner loops do not check for pending signals, the proactive reclaim task can remain stuck in kernel space for seconds, failing to enter the refrigerator in a timely manner. This leads to suspend failures due to freeze timeouts, a behavior observed on Android devices. This latency issue is specific to proactive reclaim because of its large, user-defined reclaim targets (could be gigabytes). Since commit 287d5fedb377 ("mm: memcg: use larger batches for proactive reclaim"), proactive reclaim uses larger decaying batch sizes (starting at 1/4 of the remaining target) to maintain throughput. This keeps the task in the reclaim loop with a large target for a single syscall invocation. In contrast, reactive reclaim (global/memcg) has small targets (SWAP_CLUSTER_MAX, typically 32 pages), allowing to yield or check signals between attempts quickly. To fix this, 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 to the outer loop, ensuring the task can enter the refrigerator and allow suspend to proceed. The 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 --- v2: Update the commit message 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; =20 + if (unlikely(sc->proactive && signal_pending(current))) + return true; + if (sc->nr_reclaimed >=3D max(sc->nr_to_reclaim, compact_gap(sc->order))) return true; =20 --=20 2.55.0.795.g602f6c329a-goog