From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (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 D31943AF64B for ; Thu, 26 Mar 2026 08:38:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774514291; cv=none; b=k3VawL3KjR0ttqI1539vkccpCjEfIau1Vt2qsmR8BqGjbg1NjfuoADm7jvctk3yybTxoZI60enWNA5uK173/dkCviJV+qGzHUJzYKeLHzv57wbxCIh4T0mOzq67wbknIUfI0qMdoL5paQTZI5qrbe76ZGOntfhZn+6LwF/j55ws= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774514291; c=relaxed/simple; bh=YdiZbI44YR03PZ/zRiCgk9x2jnbKh390w1oJAo8h4E4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rrDOMuiceODnRdoUrSQ96JMPXYCX+JsHM2fI8Qhkys3hWo4JkyrEVbnuh6hW2zQ5oaRvxGpwWpaN1hrZP0b6/aRfXY4nd0z7hsaKyUcqOOxh2+8eGOJZ3lsAA0SYy7sz6Gq56m2uvPjzZcDOS8TGGW+2n3hjTwhCJ4qUBN60lDo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=aY8bG4Fg; arc=none smtp.client-ip=209.85.214.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="aY8bG4Fg" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2b04d051664so6692215ad.0 for ; Thu, 26 Mar 2026 01:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774514285; x=1775119085; 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=81i9wdPvvQUJba9O0FvPBNBq65mKICDQrREUxrxqWKc=; b=aY8bG4FgcT3XhY0cWkgmoWUZZ6pfa49mIDBFn1PWv6sCxEI8ksqpwBfn+IFIgGHSrS 6ZLNri4p5UDG+LJC0ElvvQDB1sO0IUdZfpBh+abn2bmtJ7HYItqevmEnjO6Etjr80Rg2 zOMt3+sSA14q8sfOFqfnetPh39KsvV7es9ioEECljvdopw5fKMLehjhaGNpyUx9rWnv4 BsdUG2znXRj5sF2fveYjwRAMNW+nAkTzEd4T5UPthIy01WvTaaoBPu0BNOaXCE5T+6mz 7hASTDfu1KgbmxhziUO3ew+5Due8I8BDBKIo8VqpirBaHbk5JbR/gbhyDKQMPhhbb0yT GD0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774514285; x=1775119085; 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=81i9wdPvvQUJba9O0FvPBNBq65mKICDQrREUxrxqWKc=; b=PUU1oQYD7c8XGymjzMrKVwmnLz6uGoTauZfueugtnb4RmX28KDl2QthG6YGlpYi8cZ sRiVbrTIfx4pRk7MvoynvkY0GnwuZ4qApfaaKs5xC/Ui1NABdvZmmvc/Oq38NGt2PLjB yMcWIyQV2SBMvV77A9z6l6A6mUAND9hLFFlYZt0R06H20KmQpKpwP7YgiBtw9OIkm0AP OZYMqYEfdKtI3/C6ghGCXr2mS/mljGKNtyiuYMVCyB7cZFhqVhSIwS8LydOTaNWsrQJR /2++y1/36RWvAN8bCza7ICBy3y/LqvTcyeLC9jXkFRegGpS4/WbsaoykhE2M0A65E/D9 +5/A== X-Forwarded-Encrypted: i=1; AJvYcCVY5H9d13jBxxDRs92Y5pusv3h4qsSdxvvyZRm2p9AIUhb/7PzP6FZ5xCvR7zdTkMHI95d6qxupMoJLNK4=@vger.kernel.org X-Gm-Message-State: AOJu0YwOSotiYUsd6kMERY6N6NlstuTyzpsVLMG5XiooYTEvVCScQ7Lr 4xqV5lQ2vIEsOYP4Fi3UQDsvcf4mPh78gzKauMM6yCqeGr6EOlcIbosH X-Gm-Gg: ATEYQzx+c4MJ+4v1WjLZnIHvtHQsGrJ7VkvKCgdxa9RbC/vMPkZG9LMUgtrPd+84w6K JxYoPb5sjaK8b+xCiUsa1ntGCeik3ZrgbQABxIF9HFE461vlT8/x7wXZdceKdpSPd8YJ9+N4Epu 5QfTForFBvc1R0lreVnOwCG7W3VCkJyRaiv2veFC9CEZ8hUTH8euJ1Ym8u70SpM8Go1yGn698hR VKzuM+TmSGt2pUnViKQsZexhvZ5FlrIltEs5sPCIrwgOtybtjLDcjLQtcy0p+96rbjousKnn83s PX84wRpYRrJGas+vUxaYKy/Tu0BydSOpjSIWFOYfk4prWiCnwrmrUD+ZlO3X6B29MQZ1iB2xVZJ EqHVOnz/5HJfCQkNgyvscVAIP66fPALzHfzsHI/b9+cJd/4SG/9noPAeRVw9SV6rqgjUk4imNOO ZukXAfwvj8+2k7DHJpMbBp6EnHbd2ySux+fo0hsGZ8aa1qKVTs2UKM2Ye8vqZrWFHnva0Lpb0O4 5e7Y1U= X-Received: by 2002:a17:903:2ac4:b0:2b0:5b4e:370c with SMTP id d9443c01a7336-2b0b0acff88mr77777595ad.32.1774514284992; Thu, 26 Mar 2026 01:38:04 -0700 (PDT) Received: from KASONG-MC4 ([43.132.141.24]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b0bc76f1ccsm22844545ad.12.2026.03.26.01.37.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Mar 2026 01:38:04 -0700 (PDT) Date: Thu, 26 Mar 2026 16:37:57 +0800 From: Kairui Song To: Baolin Wang Cc: kasong@tencent.com, linux-mm@kvack.org, Andrew Morton , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Barry Song , David Stevens , Chen Ridong , Leno Hou , Yafang Shao , Yu Zhao , Zicheng Wang , Kalesh Singh , Suren Baghdasaryan , Chris Li , Vernon Yang , linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/8] mm/mglru: restructure the reclaim loop Message-ID: References: <20260318-mglru-reclaim-v1-0-2c46f9eb0508@tencent.com> <20260318-mglru-reclaim-v1-3-2c46f9eb0508@tencent.com> 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, Mar 26, 2026 at 03:31:43PM +0800, Baolin Wang wrote: > > > On 3/18/26 3:08 AM, Kairui Song via B4 Relay wrote: > > From: Kairui Song > > > > The current loop will calculate the scan number on each iteration. The > > number of folios to scan is based on the LRU length, with some unclear > > behaviors, eg, it only shifts the scan number by reclaim priority at the > > default priority, and it couples the number calculation with aging and > > rotation. > > > > Adjust, simplify it, and decouple aging and rotation. Just calculate the > > scan number for once at the beginning of the reclaim, always respect the > > reclaim priority, and make the aging and rotation more explicit. > > > > This slightly changes how offline memcg aging works: previously, offline > > memcg wouldn't be aged unless it didn't have any evictable folios. Now, > > we might age it if it has only 3 generations and the reclaim priority is > > less than DEF_PRIORITY, which should be fine. On one hand, offline memcg > > might still hold long-term folios, and in fact, a long-existing offline > > memcg must be pinned by some long-term folios like shmem. These folios > > might be used by other memcg, so aging them as ordinary memcg doesn't > > seem wrong. And besides, aging enables further reclaim of an offlined > > memcg, which will certainly happen if we keep shrinking it. And offline > > memcg might soon be no longer an issue once reparenting is all ready. > > > > Overall, the memcg LRU rotation, as described in mmzone.h, > > remains the same. > > > > Signed-off-by: Kairui Song > > --- > > Overall, I really like the code cleanup here, and it makes the code much > more readable. Thanks for your work. Thanks for the review! > > However, one concern is that you've mixed some functional changes (such as > the offline memcg aging and shifting the scan number by reclaim priority) > into these cleanups. This makes the commit difficult to review, though I > think the functional changes make sense to me. Right, so I also include very detailed test in the cover letter for each step. This part of code is kind of coupled together so by decoupling them, it may get more messy if we try to keep some of the trivial old behavior. But will have a try on V2. Already doing some stress testing but splitting the patch shouldn't effect the final code.