From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 2BE6E1D5151 for ; Thu, 23 Apr 2026 07:50:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776930652; cv=none; b=SIlUKbSmon/RcPEIzNn6peKS9CMyGbRBbypkcAZ+HQysXi2SYTKD6Mne2XmfRvEdtZp4GrBj/2sI8QUz7sC1KEx7IMcl2Hz4UpXy0GAl3IR8YBb/8jElDXu25T010GoUvhnkaEhCJ52br6o5SAz3XkxqVBb9xe2xawAjhSjoB7k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776930652; c=relaxed/simple; bh=7FvkCR8QhB8iUlmv5fo/1KuAEbCOzOEtGTcU0XLSGZ8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LxtNM5pLa8KV83B8osKnljnpKujD/jkFCJqsaoIALBllDy6zy3qHOrpnp8UN+uMsac8ThDQZoxvdM9Izn4rUX/Q7t6HquQfgxqPjBkfeUc73xLYQbLkwGwLgexXZWTrKevhJIoWuecL46xfw8n4YwadzIN/A4Eu8IkIXo9elWOY= 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=VFCNve1S; arc=none smtp.client-ip=209.85.128.50 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="VFCNve1S" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-488b8bc6bc9so44940885e9.3 for ; Thu, 23 Apr 2026 00:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1776930649; x=1777535449; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hAQn0n2o5JV9MpfW+watOd1u204lA4QQnaZqSDSP20g=; b=VFCNve1SyvTq+flZgC7BQLlhxRA0BijmGTiIYzex0Njxh32mKL7302bAbrdfHHmjp3 1GgCeJ7S2m0O9sxeBWkwmuJFjcb67O3Toqnb41SpM3mNlZVo0501IQnu8sUTmEhg+gyK aTpT9zKx0mJ0ipjYxybq9igEIY6uKjYmOa3P+p7Q6ia+pVOK6zZ/L4waPqILiSEK6qSY R90e1qmHV8rx8A0463ABRpdjoN/w3Wte7doLMswRcPc50UZPwKNi0GlTOwdBPQMx1xcD gvpOv6kJ+fHDRf63yZ4H8s13TGNcqHo1pJlZTci/QvmOxAhLHzU2ocr63BcuiXJvKVZS uBSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776930649; x=1777535449; h=in-reply-to:content-disposition: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; bh=hAQn0n2o5JV9MpfW+watOd1u204lA4QQnaZqSDSP20g=; b=lc5mNakvcL4ICHNun0a/wEMq3UyVPQvWwvsGFHVWJ/ZwrL3JeBPeW7XFAK6O7ibMNd P3EnphZ/e44AJzq02xIhL1gOZxBvL/8jFl1dUUX8k1Deso2hkIhw3g6/zIqt6VMDsqAO ds/Kemvf6JwHZ8GRr0WkEnV8eRWThgfjjNDVmmfQ1yQYb0srdFTEoz3u4/qNlYmhuLDp zdDBUydXDOJTYY/kCAnFvRViIJQt/7IorDT5z1ngaGZugBA8wVrjjUiHB/8o4jhuM9Lk XZ/TrmFlEiBRjDBKIzkVNIOYzssRv4A1Cera8D/SOWRTPiXGFnFb+OodVvsF+nRcqa6B G7AA== X-Forwarded-Encrypted: i=1; AFNElJ+2nkhPMgdTffcY0sbzfNqR1OEN2T/5h/jSMsaAiUDva8vePPQWpVkIVqj17zp6IE6POu8VckhAr25WKXA=@vger.kernel.org X-Gm-Message-State: AOJu0YwfO5V8m8Ss+T9Cfd3Tm9hqx0OOa5ALoQZIMZnbgkwYub7VJDtf NKqDRQoRDrIEccc7lopdvNYWfmkGZ7fiLDk/7N2+u0F8Zto7acbvzYV7wgkAQgLSK3w= X-Gm-Gg: AeBDiev0niEWO1A7rjjv3TXsB3nWHu5Ec5XT907NLfLcitPwUVZOLsAX00ZY9qchqnF nCJQsjfCJha+/rCt7vvMvybbSGIQyHQT6WEu4eH8OOMSxqCqMguV/GlZ7PpPu+qALr2sjQTBVAG CI3bx9hQ3j6eBQmNb2WrYOgJHUfqr/1nOYwNCl7nY4jlMwILayPIIWoRziTVEYEVEKOUN+GterR 8Uv7GRrtcRFVMaFtWfY8IpCFNmo3ATlMaAZkkjtgomUZmbMqVoFg3TdmZXZA0aOmnnHi2BOO+xx gxD01N4D4LeW0LQj1H4MEhpwCkbZW7Tjvd2dk58tcAG7euIYxxYP3x6rpnKiXrmUfkhXxk4LYDV wE6sm2sc03vXvbXhtX0K64MgiFA9Rs0/IMd8Yk1OWe2K7oMrsIfL5HuLe2b21LrNu0qR4tIjUhN y6P545kMXqNm84+VP7k04xkjTgMpZYQA5pDc9P6Qy6flUZ9wk= X-Received: by 2002:a05:600c:a30a:b0:48a:581c:ead with SMTP id 5b1f17b1804b1-48a581c113cmr101243955e9.10.1776930649398; Thu, 23 Apr 2026 00:50:49 -0700 (PDT) Received: from localhost (109-81-17-171.rct.o2.cz. [109.81.17.171]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488fc0f82bbsm859823795e9.3.2026.04.23.00.50.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 00:50:48 -0700 (PDT) Date: Thu, 23 Apr 2026 09:50:47 +0200 From: Michal Hocko To: Minchan Kim Cc: akpm@linux-foundation.org, david@kernel.org, brauner@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, surenb@google.com, timmurray@google.com Subject: Re: [RFC 0/3] mm: process_mrelease: expedited reclaim and auto-kill support Message-ID: References: <20260413223948.556351-1-minchan@kernel.org> 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 Mon 20-04-26 14:53:23, Minchan Kim wrote: > On Fri, Apr 17, 2026 at 09:11:21AM +0200, Michal Hocko wrote: [...] > > Yes. All which make sense, really. I am still not convinced about the > > clean page cache because that just seems like a hack to workaround wrong > > userspace oom heuristics. > > I see it a bit differently. When paltform decides to kill a process > to free up memory, they want that memory back right away. > > So it doesn't make much sense for the kernel to ignore that and leave the clean > file pages to be picked up slowly by kswapd later. > > In some aspects, you can think of LMKD as a more specialized, userspace version > of kswapd. It has high-level knowledge of process priorities and knows exactly > which process is safe to kill to get memory instantly. The kernel's kswapd, > however, operates globally without this specific process-level awareness, which > makes it less suited for this kind of targeted reclamation. > > If we force LMKD to rely on the slower global kswapd to actually free the clean > pages, it defeats the whole purpose of targeting a specific process. > > So letting process_mrelease speed this up isn't a hack at all. It's just helping > the kernel do what the admin wanted in the first place: fast, targeted memory. This is a very creative/disruptive way to do a memory reclaim. From a user POV I would much rather see clean page cache reclaimed before my apps start to disappear. But this is obviously your call and your users that will care. Anyway, I still maintain my position. I do not think it is a good idea to drop clean page cache as you do not know whether there are other users. I am NOT NAKing this patch though but please make sure you have a wider support for this idea before this gets merged. Also make sure that all the above reasoning is part of the changelog if you want to get this merged. -- Michal Hocko SUSE Labs