From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 7BBBA3845CB for ; Tue, 14 Jul 2026 12:40:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784032816; cv=none; b=bLScnhl9gbuI1InaLRRh0sDEh6zB7PjOLCiavklYxET0yhUYqCxGsnmdfvFdsQ9yhbeMewMbMmrVulfXa7WxQvS7DY6Xr5e/Sq8kUGVLV/o+jDtUu+Tcmr/7+P/jmSqrZoEmCu7D0t6WgljOR9s2nOFB5oPQENFo+aKlShQ1yBg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784032816; c=relaxed/simple; bh=5urF/3LBIdArUZ4wuirQSj1Qz2hQ4NvINgIvtvVtYgk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uHoYhg+/ipK3vROcaaAvFu60qsk1wgSKcWzPTHAA4A5B14z+Qbea2k6nDAwJ9RXckRSJegbn4IsquDKVbjR07xb2qsoZ6ImlgabINn9vJW+LR9s0F1Wq5nZYDG9BEHtg8/2wqrnI5TdjcJpC9pGT8pt8I7qeppQ3i36N1kvhM0Q= 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=E7ImHnW2; arc=none smtp.client-ip=209.85.221.48 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="E7ImHnW2" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-475cb71a4ebso4069389f8f.0 for ; Tue, 14 Jul 2026 05:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1784032811; x=1784637611; darn=vger.kernel.org; h=in-reply-to: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=owHKmrLeWwtOxoZ0SVDBcimIGdjvIGLPxWpdQRnedLI=; b=E7ImHnW2ehk68paSUfwiXDPfG9jxYGZ3lZ2WoB2b3Dt7KrL7A5Vjbqg9jjHYmQ1VKl VQmDNxlYkUQxROGLoIwxvrNxfiX9uSxSHe5V18d62pbHx2DADNCauGm4zqOQ1eBYkZ8c uVpjz+p105rGcuI8bBcBv7KcymaKpXt4nDO+tCu++KhGnbJq+HZUu9o2r34l/2EWk3S2 iagq3lzC48lxomnVKMgS43X8d2kekDlN3FmEhKk0x+iiHggXZdtqj0uLxkY+aXiRFguy BF2FGhE1LtlQZro/BtDX8xJvzNKG1LUE1WuTuFHEiHiYdF+oyyw8FN/+3bRDn/1cahs5 GKYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784032811; x=1784637611; h=in-reply-to: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=owHKmrLeWwtOxoZ0SVDBcimIGdjvIGLPxWpdQRnedLI=; b=iplp3M+JHIfte8MwhI9tPkaRPzVBGhBW9Mt2cCV0ZnLEDjCbjsns0Au4ILvexvog1s BbZzuncQDUpHtNt7Q2SoBK2qeQvOeKgWkV/kDjruyzGoOulobW2DlHA4CdLILcamGTIZ PPRESRBieTjEEqrJ/8+k/8dtnhEwTNGA+EG57vQF1QHnhzpdvwJ8Unz7t3C5aHMeQF4k aS9dYJ/OEvI8dQaud7k57NpbZHBs8l2qi3x154xwQvu1xO71hQW6mEBtJrpfzTmNHTks BfELg4EIX8vdQ4b3wDliVRkWtw07tHk9IRk6nFC5KxUqTjdhNqtQx1xOeu9+w1QHy7E8 aHHg== X-Forwarded-Encrypted: i=1; AHgh+Rrh748/3oct/En1nYhPAXryE3tf7BHf99pXjKt+B0LuUlwZztqdqPPD5Dczpnp0ju7zGW9/F4k8TDVmlG8=@vger.kernel.org X-Gm-Message-State: AOJu0YyJtbj9wuTimITwbG8RYABca0iFyypA0gcMwlZzyIhC+u9CY645 MfLgqxIlfVwLwctwVJJsIan2KAgMY/lA28wNKYTrGIpCtWjTU7AhgDikEhIrz+x6ao8= X-Gm-Gg: AfdE7cldHxe6tNjqr3f516SRlplzINHXOnBtXK/DwAUDUsuzBg9s/aUW2z1y5rC9BH7 GuIiEJPCtgtKiQbHZAYnscAgVz0tH11e+VyK2LONNx5iH6ZWVFSrTbCLZPXnU7sRDonA+pciaTR Tao0cS0zJ5ng2fbRVgcSGdgoN41vDaIZkX7KjZmRJFCkFJNASNPfjEOFJkgbv6MploO0b8XNDef 8ZizKtr2yoOqHVypHgDaQowA3M2i0bTnCDZlTDA0Eiq8WgG8jXxM+2DnalcnU/LN/8LOtiLLlte u3PpxSnUoUdB0kjosjQUyIHD2+ple+1stGyVnJhMIcFvlpgridIj4KAd+MfAsyC7eQGNEO2rQ2G LitsIQnLwXex+4MuqHnUBnS/BFEHox4Ppgd9KyC/4R+UCAlRC1GieRasAmBCrD6LEvw4mnqowok hWZ+Cc1MKmGNNVnONjy+JwDbdVIw== X-Received: by 2002:a05:6000:250f:b0:46e:8226:96ba with SMTP id ffacd0b85a97d-47f2dcb517dmr16034732f8f.13.1784032810707; Tue, 14 Jul 2026 05:40:10 -0700 (PDT) Received: from localhost (109-81-95-153.rct.o2.cz. [109.81.95.153]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f4634e5c3sm7804069f8f.1.2026.07.14.05.40.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jul 2026 05:40:10 -0700 (PDT) Date: Tue, 14 Jul 2026 14:40:09 +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=us-ascii Content-Disposition: inline In-Reply-To: On Tue 14-07-26 14:23:50, Michal Hocko wrote: > On Tue 14-07-26 17:00:37, Richard Chang wrote: [...] > > On the other hand, the freezer timeout/suspend failure is a genuine > > bug currently impacting Android devices in the field. The proposed > > patch safely addresses this immediate issue by leveraging the > > pre-existing -EINTR exit path in user_proactive_reclaim(). Could we > > focus on the current patch and open a separate discussion for a more > > ideal, long-term design regarding freezer invisibility as a follow-up? > > I am not insisting both to be addressed in the same patch. But building > more on top of a broken behavior is not healthy either. > In the current state this should be as easy as turning signal_pending > into fatal_signal_pending and try_to_freeze at the pro-active reclaim > entry point which should be safe from the freezer POV. Something like the following on top of your early break from reclaim patch. Maybe there is a better way. Freezer has always been quite confusing to me but this should work AFAICT. diff --git a/mm/vmscan.c b/mm/vmscan.c index 35c3bb15ae96..3795734b3a22 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -7909,9 +7909,15 @@ int user_proactive_reclaim(char *buf, unsigned long batch_size = (nr_to_reclaim - nr_reclaimed) / 4; unsigned long reclaimed; - if (signal_pending(current)) + if (fatal_signal_pending(current)) return -EINTR; + /* + * Make sure this potentially costly operation doesn't block + * freezer for too long. + */ + try_to_freeze(); + /* * This is the final attempt, drain percpu lru caches in the * hope of introducing more evictable pages. -- Michal Hocko SUSE Labs