From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) (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 C49884035C7 for ; Thu, 26 Mar 2026 15:24:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774538673; cv=none; b=mJSFetC95jyI+WjC2oFBrkCEuA0tlyk9JSPXvgEEmrMRfDW4rZLCFRBXdHSTV8QvatAgZZ+LERYNsN50BPUfujN81PhP9Ja1/CMVN9m+f9h0OYijM5dIs1qC9TaBVvAT11EPYqhsNJKJ6/9wULXqG77Bp1+O/xWv6VXEPevoyy8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774538673; c=relaxed/simple; bh=nT+Xs3xIbIaPyc7WwKRINCLOr1g7D3DJ1PJ9Uud6yaw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uafUYx3fzY4JZ/AzBeiF9RjHx6a/J3rNkQL6DMlHchbGkuGu5//CUMxxvVWZVUH0BD+4yo4JuDUyF6re+N3Cy+KEKmvoe4D5NJCN1OuqebQC92mqK78DBCc8dfhGLIt8baY5UwUJuv3LCyNsijkaKusGGuQ4P96zklVhpkLspRU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=HVV2Vp/+; arc=none smtp.client-ip=209.85.219.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="HVV2Vp/+" Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-89cc68655f8so11862166d6.0 for ; Thu, 26 Mar 2026 08:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1774538671; x=1775143471; 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=bIk59MTMskTJurRtc6jFkcPp9I+cldWKz4vCxcp4e8Y=; b=HVV2Vp/+3ivH1JihZueLh21JMGPF9hZB6P8eFpnqBIyvtKD6EbzQqKiZ00nrZkQOec ouwxmLDfuSBK3Psp9HnjY21fZSrC/oZEGkLnJjrkxYDtOIS1mHBu66FAr6p0ziuCrDFM fHsTd+7fyeMt3RG32oUNUN5RgUi/tIQntAQ0bHHfAZ2A54iD/5stmUAsWEE+A06gS1tu xLo2HHXkwftp6cl3EklMUywkcsQVW3mMd1Mz0NdzVxsaAcohh/w4Jud34MgC+H7tuLPL 7kVi0TLZmCjkxca5hqTUHyaEVNzYajcS5QgkOgeUj8Jd4ABECBwYxRd/4TLeoptm/4k5 mQzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774538671; x=1775143471; 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=bIk59MTMskTJurRtc6jFkcPp9I+cldWKz4vCxcp4e8Y=; b=BbkdOi+aUlJTi9tuiFhwK3Dh/875wMeP2htf74xwkfN8xuMeHvyddEyhBrsCeOzXre 22gc8aaQuTuLjFgXMAqWEQ5nAKBXf44mqN3sBSRaxgsnSpMZRE/QTL4/RTHVnavVZRn/ R84FCdSMPclnw8CI4IDCSFPdyH5ScYxSq7uRGJ1c2lF0D6+zoOTvtW3726bPnNjc29lT EDmVRS/KMdSJL3jssuA0d4b86v4FGIIA0znjHCqLGR380NdMa6pnU0h+RwkoHnfujYoe x2q5vj3OJakLmUEugs+WgHAyHnAQv8xVkuPzchWm+b265J2S78MnwjR7jYdbrWPzVepA WjbQ== X-Forwarded-Encrypted: i=1; AJvYcCXuaOxozk6bLluoSx+sPhUCMr9YSrb47qAYlCFAhhGmM2iHJpfhj87lqyNgqGHl45Mv1oICFPsWyTbLgbk=@vger.kernel.org X-Gm-Message-State: AOJu0YxnUt5h3XNs6tFp37TauTKqbuAnPy+A/2L0DGqA4th/Gi6CChnr sQv6V1mBSYMZZJAoOTKcC/MQHF9B3wWfkCpu3387dy25u0gpxWOjQeQyijc7yRWJEJQ= X-Gm-Gg: ATEYQzxyQz/B8bnhhFJvCoWGkSMkokWlPZdWgXMjQcY0KU7J3GoU+vdAuoVmuhhG9rs +gNfYCRDCLjozW+EPdNolBvu4pXm9IOzBxXzpWDbi2x3GzTPOpZ+UQpZ5vJKydFG/q0Jw6v2tba KcUo1OOOq4yLKiuc/QmWVIrCnR7N76GTe2iCtgAHOoBJxYLTF8l38Lh+VGevOwk28mLS/maaQtu QAxr487HNmMMvjHFEAZUJ1aT4O3usSsZe38tm1B1yf9SXCR6cpzYHinjpVpr8f+Os/DknM4CTrU /s3FW23AN2mrMzaDz1FVY49/vUfHzzYwUNSU/zcraYlVQyxucm58P0RZXcwsCD4/HBcdBpxiDQA kEzS/axBdeaFSl6aGqjj4/z6ueQNWRWwyRABj9qvYl3NAk36Dw7k9f9Y8ckRdW6XtkMXuiBuIEj rWrwLysRFSx5ndziRsMZMjKplq14fZJZ8= X-Received: by 2002:ad4:5d43:0:b0:899:f495:1a17 with SMTP id 6a1803df08f44-89cdde45098mr24691616d6.15.1774538670605; Thu, 26 Mar 2026 08:24:30 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F ([2620:10d:c091:500::2:e5e8]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-89cd588487dsm27153366d6.11.2026.03.26.08.24.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Mar 2026 08:24:30 -0700 (PDT) Date: Thu, 26 Mar 2026 10:24:28 -0500 From: Gregory Price To: "Lorenzo Stoakes (Oracle)" Cc: Shakeel Butt , lsf-pc@lists.linux-foundation.org, Andrew Morton , Johannes Weiner , 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> 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: <42e26dbb-0180-4408-b8a8-be0cafb75ad9@lucifer.local> ... snip snip snip ... > > > > How Do We Get There > > ------------------- > > > > Do we merge the two mechanisms feature by feature, or do we prioritize > > moving MGLRU to the pluggable model then follow with LRU once we are > > happy with the result? > > Absolutely by a distance the first is preferable. The pluggability is > controversial here and needs careful consideration. > Pluggability asside - I do not think merging these two things "feature by feature" is actually feasible (I would be delighted to be wrong). Many MGLRU "features" solve problems that MGLRU invents for itself. Take MGLRU's PID controller - its entire purpose is to try to smooth out refault rates and "learn" from prior mistakes - but it's fundamentally tied to MGLRU's aging system, and the aging systems differ greatly. - LRU: actual lists - active/inactive - that maintain ordering - MGLRU: "generations", "inter-generation tiers", aging-in-place "Merging" this is essentially inventing something completely new - or more reasonably just migrating everyone to MGLRU. In terms of managing risk, it seems far more reasonable to either split MGLRU off into its own file and formalize the interface (ops), or simply rip it out and let each individual feature fight its way back in. ~Gregory