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 BF6D722370A; Wed, 8 Apr 2026 06:49:05 +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=1775630945; cv=none; b=sdf2Q8tYg1UKnWfW5yqELU4uBUJ6osrn3jLQOq1JaL6JZJtszuX5yF9RsGUvFM/urkAHpty7gKoLKbdesshIE7lGpA7BIoupx83GgvXyi8E06PSmjZI0tYgyFWgz1Xoxkw+YEbUj9kRa45UigYeCNAAKYkTQ43cPh7Q0sNwTtd8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775630945; c=relaxed/simple; bh=Jf27xk2PEb+D+m73rLzzPti70YoNYsdCvSbCyz5KRkY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=td+Xf/8pXJLn/1ed8nDgh5OhbiybwDxAXiazdXlNIZsbEZaJDHs69TznzAuJaamnXHyEvGsYxLrdAkcZf/tHVi3JlQdG2jifdTxnZ6Q966g8PJSAV3dqTA5G6uHvbIBkpyH3quQ5qu31W4vbxTIt4Ba2uvipch00X3K2gYtWkyM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O4NFTZAU; 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="O4NFTZAU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39DA8C19425; Wed, 8 Apr 2026 06:48:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775630945; bh=Jf27xk2PEb+D+m73rLzzPti70YoNYsdCvSbCyz5KRkY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=O4NFTZAUGXJlYJi1cB1XvfzxzdGTopyBo3L3YcY86XA142N96ZrAP2E8Z7cICnhLE 6AeES82rZ1GsQxLKVt6MkUHPfg+P7aIRFJgyQpgbmVrbSsa7jW85ipzT5C6LDcS0XP gRoSDzQgopOYGZbbOnFfFufWbjcN0mV7jrsb6rLPGUY7f4w4xUxlKOoWXKNQODNu2E mZd3Qix7Buh60T4+rmK4cx3a5t4M4Pm5adIEofTwJpiX1TKY3djbBbAAYSinFuRLaI RP+58r0yTBQ6QMvYP/COqOMpaf/w8MiS5qx3fyLn/tFDdAP7Z2ZdXxVtxUdC6c2c// HJbDftmUH6B0w== Date: Wed, 8 Apr 2026 07:48:57 +0100 From: Lorenzo Stoakes To: Gregory Price Cc: Johannes Weiner , Shakeel Butt , lsf-pc@lists.linux-foundation.org, Andrew Morton , David Hildenbrand , Michal Hocko , Qi Zheng , Chen Ridong , Emil Tsalapatis , Alexei Starovoitov , Axel Rasmussen , Yuanchu Xie , Wei Xu , Kairui Song , Matthew Wilcox , Nhat Pham , Barry Song <21cnbao@gmail.com>, David Stevens , Vernon Yang , David Rientjes , Kalesh Singh , wangzicheng , "T . J . Mercier" , Baolin Wang , Suren Baghdasaryan , Meta kernel team , bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [LSF/MM/BPF TOPIC] Towards Unified and Extensible Memory Reclaim (reclaim_ext) Message-ID: References: <20260325210637.3704220-1-shakeel.butt@linux.dev> <42e26dbb-0180-4408-b8a8-be0cafb75ad9@lucifer.local> <248a126c-43e7-4320-b4bb-282e0b6da9c4@lucifer.local> 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, Apr 07, 2026 at 02:37:53PM -0400, Gregory Price wrote: > On Tue, Apr 07, 2026 at 06:30:55PM +0100, Lorenzo Stoakes wrote: > > > > > somewhat trivial work these days via with > > > reasonably well designed interfaces. > > > > Though to be honest, I did ask Claude to do this with some code before and was > > really impressed with how quickly it came up with something. > > > > Buuut I've generally found the code LLMs produce... terrible? Really terrible? > > So I think you'd want there to be some level of human improvement there. > > > > And in any case, maybe doing things this way will struggle to really represent > > real world cases (lock contention etc.) but OTOH, being able to simulate a high > > memory pressure environment with certain parameters even without [the rest of > > the kernel] interacting might still be super super useful for diagnosing issues.x > > > > There is a concern people start looking at these tests as signal for > performance regressions - which is neither meaningful nor useful > (unless you fundamentally break list iteration or something). > > But for trivial cases, you'd at least like to know under strongly > controlled aging and reclaim scenarios that anon/file memory is > reclaimed in a balanced manner - just as an example. > > If something breaks THAT assumption, you know there's a logic issue. Yeah and you could assert a lot of things like this, for me the real value would be in extreme circumstances which might otherwise be hard to simulate. But it'd be testing very specific things rather than 'how does an actual kernel behave in this situation?' > > Likewise with comparisons between LRU and MGLRU. It might be easier to > identify the behavioral divergences that way. > > But i fear the whole page-table walk thing makes all of this a > non-starter. That's turns into stubbing out like rmap and such. It could grow exponentially yes :) it was hard enough isolating the VMA logic... > > ~Gregory Cheers, Lorenzo