From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 41ABD3F86FB for ; Thu, 9 Jul 2026 12:06:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783598798; cv=none; b=L7RClpkvNYDQIJ3T1iBYmlksMuuSTMhyuanwpdtTB75+W45CXs/6UHb/jaFJ+6V30dx8Hj6mc81umAdC+dXsti5gi8YH64CJ8zDALX8MVYizcsZro1JG3tBQaKvqbkj6omt9LnhsbpK4fIjguKNT4ZwTSSV5BGSkTtMEvrKRrDo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783598798; c=relaxed/simple; bh=EIX4gOj1V0TtH5PbiysQldljJtALpcccgIwn4E/N5/0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=o5bwnm1I0iyzzMbx81T4HfJvsgU71A8HJIW56sWNB5xmxG7IOPHVoRDPynOEO1Cmjj/HpT2Z/HjzClTqreHPmE+D8MAX8Yu3OBEp8D0/AsNShFxLe3BelPM/FsK3Q6/fKrFx43FPolowDSQB/jJktUrJq5zqiABEJOmzvaID10s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=B07J5CiW; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="B07J5CiW" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-47df440fcd5so781361f8f.3 for ; Thu, 09 Jul 2026 05:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1783598795; x=1784203595; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to:content-type; bh=mJCJDiZFMnEXRuWNVK0tV4OPx1m/p/2vz2kgTU12GDk=; b=B07J5CiWhMfFQ8kTRv4MxAJiXXVFXGz8CIMam3LdHYcfbQCR/CkmwxdnOzlTJAeKZ1 Cj0EvVq8shmQVKwO5wlBZlc+jEfkceVMsmQLCMBROfdTJt2r6Y2HYy7GeqxMfafbO9GI dR/EHcTpzW0aKHs0LGX5RDsvGgQQRRArqB6+yEdGKoc/pHCZ5VsxRzQ70hwtE/TTk7Ic x2qhe6nahfGTM3d7KhqKFNmPK7Musx9q81/zcRw1whQ4LikqJX6CU5GLq4JQ5snGvraS dcBGi8CeASXrC/CRruAZOaNcTWDWsuT2oc1bCIRv7EHahCy7OhQl6IJJExBcofa2wPPc b17Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783598795; x=1784203595; h=in-reply-to:content-transfer-encoding:content-disposition :content-type:mime-version:references:message-id:subject:cc:to:from :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=mJCJDiZFMnEXRuWNVK0tV4OPx1m/p/2vz2kgTU12GDk=; b=IEGpkQcWAo1zA++FBugjd/DThUQsQIQcoNGyhSqLl+uctgZfMy6eDC0P8JUntVMJ3X 9u3c9c+RDp/ZWn0Zb8MfD8rILYuj5o2wDYMfZuYONIM1c1DP+DfKhT1AQadgxmxUbMLu wW48o5LFq3ps+MWSDJHqA3X7DmNOZgQMH1WrLp6kuwWYdIa52aDb15ZTfaxOuP3XKNcD zvXB6of4qT0zkQxZKRIr/9cHOWkS/lFSq4XEBJTQECwKtPXJ4jRTiHxdsNTencAC2OXE /NpmtIHSuWWHEG/WKGGSmIxl2fAILhjb1DIDneajMZTSwjRrgu4VcXAABEKbJuDqyAqp SRIw== X-Forwarded-Encrypted: i=1; AHgh+RrMzdYciGHl0FpSzRLVRcYqU5GvSeCh0Pxzo0GLHAjS5zy1Rg+iFHM/jWiq46VsuNGczwgudDI/MaYH9c8=@vger.kernel.org X-Gm-Message-State: AOJu0YxVWuTSBvfHAQehY5WK5TLJtgNx4A7EFjx1LN66V1MX5YSVUBt7 WMfkbuFeCuFHgPb5R9GY8hMaGKrkEHE52uBSwsv8jz5UqX2qoOL/bW3KB4nNso7ckQo= X-Gm-Gg: AfdE7cnEAROmnkRW+9z+WVC31MCKHoIwVqwB1ROPTC2LfZLYKAgSka2D/UNvJTGzu29 ZwbFllz7F3B+OQYoxSKgb2dNCqBLzVtORJd+1+e+mVaa680G/C1hMJd+7NOJvRkEwuB2yfQG+B7 A/WV65G6oZFvnV/9yaFla3VPnhpcEYTAsoKCLTU+3c84y77hM7jywoN95w4ubOiJBCIVDl1mfLk t0Co3lD4WutgEwCn93dBVLst3OriYJsoIayfU30qa609DUe5QEWAUblAoEujyYv4yudzOHfJNtS XHM5p4vwvZDF6JE4qQcwFfhMJG3eefm2LtLozcNOeWQME6tciw4WIEH27sJp9yLkybNQw826zDO b2bqavwUaayJHnBTyNgrL/Ud8N/OQiGfU65jhQESCl2x1El7CSCi0p/bJ+AV9YSR2A8IbLlpuzM SlZOXeC/1Uxt8pEDqW3oJwpJg= X-Received: by 2002:a05:6000:4b1d:b0:47d:ee7a:9306 with SMTP id ffacd0b85a97d-47df08251f6mr7580011f8f.61.1783598795451; Thu, 09 Jul 2026 05:06:35 -0700 (PDT) Received: from localhost (109-81-22-50.rct.o2.cz. [109.81.22.50]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47a9e4d780csm51623987f8f.11.2026.07.09.05.06.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 05:06:34 -0700 (PDT) Date: Thu, 9 Jul 2026 14:06:32 +0200 From: Michal Hocko To: Richard Chang Cc: Andrew Morton , Kairui Song , Qi Zheng , Shakeel Butt , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Lorenzo Stoakes , Suren Baghdasaryan , "T . J . Mercier" , Martin Liu , Minchan Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm: vmscan: abort proactive reclaim early when freezing for suspend Message-ID: References: <20260709072231.3163082-1-richardycc@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260709072231.3163082-1-richardycc@google.com> On Thu 09-07-26 07:22:31, Richard Chang wrote: > 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—specifically scanning cgroups in shrink_many() and > evicting/aging folios 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. > > 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. The changelog doesn't explain whether this is MGRLU specific problem as the fix is MGRLU specific AFAICS. Also do I get it right that freezing a task while doing the pro-active reclaim will force EINTR early return even if no real signal was delivered to the task? > 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; > > + if (unlikely(sc->proactive && signal_pending(current))) > + return true; > + > if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order))) > return true; > > -- > 2.55.0.795.g602f6c329a-goog -- Michal Hocko SUSE Labs