From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.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 1A856391E6C for ; Thu, 26 Mar 2026 07:12:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774509135; cv=none; b=eJEX4rdMDIX/spbNAU7b2SvPuTZJqnZFUzl8DbbyjH7rA3ITq5AZEzFgJA+KVvbTPXDhuhYchxyfiF8CRnEAy5KC2qxt9iQTMLdvfbKt1wUGl22SxQnuICOIaAXC+QyK2fTawTtkfEbxp6aHAPQsGzizMZi4jtseUFD4/Q2Eu4c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774509135; c=relaxed/simple; bh=je6fVXQQCNMzDWDuKBS0sFm2G6QMB8sNPqvTxydZrQg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dLdq8eO9ptq9hln62Owq25UEIRxMI42xheqV0amdXEbvf17g7dX8n/i8JBQUiNKTXoXiu/6H0gOcXjbSb48K6T/jkZIPEPA50icio4wa5JGAZzdgMBczG8ZVLs/EsL7lvUjaktBWunyaFCqViZmk09pw3uWs536mWNYXPDduNks= 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=KbXe7sSQ; arc=none smtp.client-ip=209.85.128.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="KbXe7sSQ" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-486b96760easo6377565e9.2 for ; Thu, 26 Mar 2026 00:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1774509132; x=1775113932; 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=eGB0D2sZA54TniG5EwCWeLwF5KVbzKrKiN8v1Y36amY=; b=KbXe7sSQ5R6JYZDfKCeS8NZP9jJbfdnzuELQY5mH8DJIzB2+0jbWL7w210v9SghH0H 46TCRut72fEat9BJHRbX1qz6rb289IfSA6VVKLtOmdgpY3Ku3JpXmSN/jpukHBAxVOwP mfmO0sjlgVmQvtGVtFlr0VN6n8G9dtDboMmaErkPW1mOMfZIFMaJO9D32bVtG5hsKrop z/MtCreYlGBVchY9xBDLVRh5aJDQJQ5yIkDiW7O+UBiHqqTzJyY16OlrDl/yT0P17sky akc7Mt2Wsi1QHTizZEZO5iLqjh3P90bi72JIb1LdQqUy9dKLutmnwNPy0e5iagcDuEt3 drZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774509132; x=1775113932; 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=eGB0D2sZA54TniG5EwCWeLwF5KVbzKrKiN8v1Y36amY=; b=GqvPmbTzZQeAnrz/ZLwVq77iTHjf6hzsLwSSH5mObLaY8B+3VPkVSsYRYphch3OJCz 8+sfF4xrJ5PDkx4tys6WOJakLTA72Ygs/EcJIFrcav+Gjl4SodpXBeJ0cr1g5EcwU7jP KzxOV/LKSEpRzLIjDhZSVu2hvq5lKthdNyFyFY8WxyeTlg2w8BVFs9GDGkBNLQ+BfHpi b1gmbroMSAD23jxdiCfSjwvHJ+GrRPtTqaNDmaFnIauxvcs/CIHB3uv3EG5Pd/Hg1i/E 6MIl5+DIo1wCXaAWKK9zXD+8OIfIu6b9Xq0OYl72nKRkoy1kSpES+rgJP3xwJf9ck3mb HSVg== X-Forwarded-Encrypted: i=1; AJvYcCWmADO9vHkGxYe9TwA7QHnfMFd9II1AOq+luqaRLDMXVup5u6GSgP6Bma5auS1tKrfiUrqtYJvJRvJFF94=@vger.kernel.org X-Gm-Message-State: AOJu0Yxj2I9IEc8n4lK2jm8sG7yXKVt1qYK35dIjg0aSkMHJGn1fnTbC 6QwBp7ZktT6oQNTKaGZ+4jO2Ll8pau7CelYuqgU7316mWk3JGHKjIU0Q+Gm7hH+P0Xo= X-Gm-Gg: ATEYQzxpb43mjO+3hgKkPoUo/EG5v/+7w9qJKhcb9oIgoR92IRC4/a4NRB05OZCA3Xw t8p124WwTfp71l5Bcx2UDi1DWBeq9y+zwaS8RiZgg3UKC9Oll6ggQOJIHziGjM+PlCZxuHxpAh0 UxWQlbZAmDlZv3pnD5W2M4sqGEeNGvnylSS7nRio/AS6VCG91TozHdKUhaIWc8WZSDFWhXNV3Ws vaK+/G7cmgzG8n5BGHhJcXQps3Br7FW5NSMqneWp9fIAIAQ2aEZMDWHAUbr7NG5Qry3qVssWh89 ZSbqgOCRWxWFDsZDlIAgjigw+XFngZ8bTuueTaBMNKY+MUwDHOy+8PlKnXjOPuBD1e2RHdQR1Hu u25sJ5GyZJobDqvm+ZaWIe51VfZBqOsAFDmJ3Klbez2deKcu9/8s8qB9Qm4aeawJfHVI5necFas 7UQY5jPx8RsrsiEu9+wyQ9yi0qSURqyGEEXPpX0iEbMZmZ2m0= X-Received: by 2002:a05:600c:6308:b0:487:169:9f64 with SMTP id 5b1f17b1804b1-48715fea9afmr90965615e9.12.1774509132376; Thu, 26 Mar 2026 00:12:12 -0700 (PDT) Received: from localhost (109-81-31-149.rct.o2.cz. [109.81.31.149]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4871fb7f45fsm11137625e9.2.2026.03.26.00.12.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Mar 2026 00:12:11 -0700 (PDT) Date: Thu, 26 Mar 2026 08:12:10 +0100 From: Michal Hocko To: Shakeel Butt Cc: lsf-pc@lists.linux-foundation.org, Andrew Morton , Johannes Weiner , David Hildenbrand , Qi Zheng , Lorenzo Stoakes , Chen Ridong , Emil Tsalapatis , Alexei Starovoitov , Axel Rasmussen , Yuanchu Xie , Wei Xu , Kairui Song , Matthew Wilcox , Nhat Pham , Gregory Price , 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> 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: <20260325210637.3704220-1-shakeel.butt@linux.dev> On Wed 25-03-26 14:06:37, Shakeel Butt wrote: > The Problem > ----------- > > Memory reclaim in the kernel is a mess. We ship two completely separate > eviction algorithms -- traditional LRU and MGLRU -- in the same file. > mm/vmscan.c is over 8,000 lines. 40% of it is MGLRU-specific code that > duplicates functionality already present in the traditional path. Every > bug fix, every optimization, every feature has to be done twice or it > only works for half the users. This is not sustainable. It has to stop. While I do agree that having 2 implementations available and to maintain them is not long term sustainable I would disagree with your above line of argumentation. We are not aiming to have the two in feature parity nor they are overlapping in bug space all that much. > We should unify both algorithms into a single code path. In this path, > both algorithms are a set of hooks called from that path. Isn't this the case from a large part? MGRLU tends to have couple of entry points in the shared code base (node/memcg scanning code). > Everyone > maintains, understands, and evolves a single codebase. Optimizations are > now evaluated against -- and available to -- both algorithms. And the > next time someone develops a new LRU algorithm, they can do so in a way > that does not add churn to existing code. I think we should focus to make a single canonical reclaim implementation work well. I.e. we deal with most (or ideally all) known regressions of MGLRU. In the initial presentation of the MGRLU framework we were told that the implemenation should be extensible to provide more creative aging algorithms etc. > The Fix: One Reclaim, Pluggable and Extensible > ----------------------------------------------- > > We need one reclaim system, not two. One code path that everyone > maintains, everyone tests, and everyone benefits from. But it needs to > be pluggable as there will always be cases where someone wants some > customization for their specialized workload or wants to explore some > new techniques/ideas, and we do not want to get into the current mess > again. I would go that way only if/after we are done with MGLRU unification and after we will have depleted the potential of that approach and hit cases where we cannot implement new extensions without going $foo_ext way. TBH I am not convinced "make it pluginable to solve hard problems" is the best way forward. -- Michal Hocko SUSE Labs