From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 296D4363C72 for ; Thu, 23 Apr 2026 23:58:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776988711; cv=none; b=i/77S5k6ag5+ZjeTacKTt54dk8ncmjzO8Ph08PN/CAhKsBUvjR6mmTQx+OEWsm3/kPCcaArIE5hBbbcITK/FUtXVM0LdSkC5wMIto6kmbYdaWyAIEitLs1sj2Kvq9ActnrLofSB8qnUmf+GQSbpWpcppONQx9O8LyxCtfMBapdc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776988711; c=relaxed/simple; bh=/IDvk2X/nOzSmN3tu51oLrOY8xOBedWW+PR7mqnHCbE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mAMFTWvFOVdXQ+b+N9C5d4M/HqoMYJuHKjrJ3wHUYClvL43Co7t2e2vAg7HqsWRH4YnolytCQoUiUwPfKqUVoLYUYYu3GCaWq149IPFWNUEvDaGpP4Drk5CiYmGLydstrdWHAxKrDJMNqPMKT6LEka/Pc7ST9Vd3qaM48NGJKII= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WYKb8Dqw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WYKb8Dqw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88191C2BCAF; Thu, 23 Apr 2026 23:58:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776988710; bh=/IDvk2X/nOzSmN3tu51oLrOY8xOBedWW+PR7mqnHCbE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WYKb8DqwYnLGFc398UDDvzV3m3BC53w0EdyaIz2Y88hcCR5wgrFpi5zzDxVAzEZYL mkO+OUMMTA3/I2yMjX7t/cmfJacbNjiC2JFjwFmL4D6kF1v7GEmFW6ySDDUnZhumyv gXnTqPC0kjQrfmn94OcOfIR9HbIvOAbxVPO3xR2SUPonWaPTiYwnTCRQ8soGWCYGbt iHPsGohhV4NoA42tkbFfmSwJ2oLnnx7+NTGVFRaIvNXN2jUz13qPv3//DCrLjEl2mK ABzKOsmvUEmPTIPQvb75hIlQhqP7oIUsoEIE3BuHeLJbTtPIepcpFG8cW4Z5TCbMOx zke3XmP6EwMtw== Date: Thu, 23 Apr 2026 16:58:29 -0700 From: Minchan Kim To: Michal Hocko 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 Thu, Apr 23, 2026 at 09:50:47AM +0200, Michal Hocko wrote: > 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. The problem we see in practice is that kswapd is too slow to react to sudden memory spikes from foreground apps. By the time LMKD decides to kill a background process to make room, the foreground app is already stuck suffering from direct reclaim stalls, which can trigger sluggish/ jank issues which is high priority rather than sustaning background frozen apps user didn't use recently. > > 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. Sure, I will make sure to include all this reasoning in the changelog of the next version. Thanks for review.