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 95DEF371D07 for ; Fri, 10 Jul 2026 06:27:42 +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=1783664864; cv=none; b=qafwICAjZvXeG/65fSK1J8CvvgWNeXdihedz9yZCCz+QsKYfJcVondP+37WW/ORfqVkMjGlgC1kmLt68S1PzmyPdoAd1c0bZjUj/nMnN9/QoDhmKpNFfQ1Y2fnOCBoo+3K6q+OcVMejZkbzlf5JO6vLlG9Zbc5WEggfFQrFqfC4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783664864; c=relaxed/simple; bh=tEh9AEeZp5JMp3qe6bpOSFcdsU7Y6aPBOByjZgkQ0JQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uH1RFC4Oq6QnOnIR7J8HtAZ/P9cPkTJaH9Tfwhtcqj1XtjCA9Il81HJqDRXDo9lro6zNG0GSJfcNRrbAr0I6JEL4a8wozFz518j4R1Q0r6+oVvI3vXhzAuiGWDbelQuDH6G4VjnvOViQwvqkDpr7a5u7OOlp7Ofd/FNHFevirWQ= 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=VLSFSbKJ; 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="VLSFSbKJ" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-475417f010dso252968f8f.2 for ; Thu, 09 Jul 2026 23:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1783664861; x=1784269661; 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=tofb55HHSG+cFY/phPEZpv9GCTsETD3jbHewnOI3aFY=; b=VLSFSbKJnDSnceXG43vu6cf7XOCDpOuojoCvqgDWD55pZ1CkP/WCnm3Vw74P6ikIlB 8mmI7WuJ4KhBo5QmsDZ44mWkq4h8KNZe+OXCjCHOMCvXN98IuYJa21795n4U/86QcWDr FZYjEuz4fHWdOLL+6N84sU1XmJJrK471pq28U8ZmY5VCSBKngK+d3ycZMFXCAb5s3jsE 55svbNsK33tgfweUu+vGAr4OSg0yS3SeBBcJuynBGgZKmkzh7jcReQ867tw+Kt9G8yxk rGIMRGGcXke65mVQ10t8CZTWWWJ/L8UcunNICU4/fozv3vRdk8EhPIfkKDVugwSoDD6y QTKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783664861; x=1784269661; 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=tofb55HHSG+cFY/phPEZpv9GCTsETD3jbHewnOI3aFY=; b=AvzD1y83MKnBSfGlJPp7j532oelf7KFIaZ5OyhcFQb7Rj1Mp+feo7Y8jwBR/njQenC sFpUZyvs1E5eqGaujYZnMcZbKI7Eiyxii9cdb0sOlXVO1G4jGxkzizely9J7z2FaEDP+ jY3OAQLGosXcsiwyhk7iIzjikuEVYkVG4e/nxaqv2d2dsKSWfeDW2H3AKd9Z/Bm/HRaL 5vOcT3XerJNfO8fBFnlNKWy8VTkYTnMEGYG0THlHRJ2Gu5l9JGHJ7JTOtWHPmrnqwwpx b2Kpqx4SfDdn4WAArNs+HVwdKE5VFjNFQt4Qpbdwy+JeP1ZZcu+umHBh4m0aw6H6corl +PRQ== X-Forwarded-Encrypted: i=1; AHgh+Ro3ccO0UJIs51DrCbDFy4leHEAc1xN690RhxuZwyAjqGmHddqKrl/AV2aYomWrv2jRom1sCiagr2+3z1po=@vger.kernel.org X-Gm-Message-State: AOJu0YwN+wio1/GoGtgUI1gNlcXrOObHsRZX7ZKpqczBEQFGrO1v6Nlv 8jc9M8rrVn7ZdeXKVyC4c+x5EgVQMRDLovvf2BxG64yUm9ZzWa6X0RAfjd8k9YdLy4k= X-Gm-Gg: AfdE7cl8kQX6EOCqWcfIiK2nPBwWppSBtQtYV1pYZehjpPQDBVYDwE5AaA9hN3nr2RQ W7981ZsmAWiytX6fz+wV15u038r1q+mzRo05EarRaAgRwK54DpQApfRGtGYWnmcTVDIwSd5l7BO 94ZPyHRFg+B88rUyQ1vSbF36PA/9jCJXBBJL0rLm/uobGzq7U/eio+hkSx/I/5e8VTUeCqwjP9y 0pyA9vyE0QzqvZ6gJSW7KTMdMs4x1GqgOrMJTIyzpZWIxo9N9uB8Ojej0lf8YqTLEbGhXRNyOsO hHNKBldMS2j+LbHayYMsRjjBqUyw0HBmYk8vvsMybnYeTgi3l8cud93DksyWFauP9tUByl7KZiV JoDML4WRdHzPdzReu4giFl7S5vTyXxjijHrn13NrdGrmiOBA1kNH8RD2dXQRpNmGt/bs9stnVAV NPcYvp0Ej3GEF/ae37l6rMRjc= X-Received: by 2002:a05:6000:298d:20b0:47e:96f4:4a5b with SMTP id ffacd0b85a97d-47e96f44b24mr2183314f8f.51.1783664861062; Thu, 09 Jul 2026 23:27:41 -0700 (PDT) Received: from localhost (109-81-22-50.rct.o2.cz. [109.81.22.50]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47aa039ad21sm56217525f8f.20.2026.07.09.23.27.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 23:27:40 -0700 (PDT) Date: Fri, 10 Jul 2026 08:27:39 +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: On Fri 10-07-26 11:29:25, Richard Chang wrote: > Hi Michal, > > On Thu, Jul 9, 2026 at 8:06 PM Michal Hocko wrote: > > > > The changelog doesn't explain whether this is MGRLU specific problem as > > the fix is MGRLU specific AFAICS. > > > I will prepare the v3 changelog update. Thanks. > > > 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? > > > Yes, that is correct. > The PM freezer ( freeze_task() ) calls fake_signal_wake_up(), which > sets TIF_SIGPENDING on the target task. > Returning -EINTR when checking by signal_pending(current) is already > the existing behavior of user_proactive_reclaim(). > This patch does not change the behavior, it just allows the task to > exit the inner loop quickly. I believe this is a wrong behavior. Freezer should be invisible from the userspace POV. Your patch makes the pre-existing problem much more visible. I believe we need a slightly different approach. Should we try_to_freeze in well defined places in the reclaim and turn user_proactive_reclaim to fatal_signal_pending? -- Michal Hocko SUSE Labs