From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) (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 164AF238C3B for ; Thu, 23 Apr 2026 16:42:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776962569; cv=none; b=tQre6YvOvhwess0a9HuEWkOHSxeb/B+qGoZtRoFxv2yYdab5xXrH42PZOaX691hRTjFYxj07+bI9cyN6h0iCbhEsIGIvqVQGzGZy2Nl1z47vQC2mGx4CLuEiD72NO9DKbWC616Ot/vcKTJ1qWxHqu8GhXTFSsEpIUIHB5zUUf30= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776962569; c=relaxed/simple; bh=OPy7NCynu7vZxEGGc4h/rIcoKig/h6rgLp3jYy5mbgw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UXC15CjqCdqQ5ekHFnIpDcqWmVjsPCZxA6GssjI45xfXfjv53IaRYj/lfw93fnTSJnVIue94JeMYpl5P/kE6IBsotvLKdA248FOBDLu5bHPB5ZnLrKNtnYpi4hWPu+HRRcJFcR9QayxRWzOMgAFczqkSqjXpc4rQez9VKlt8RRI= 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=n9xlYiM5; arc=none smtp.client-ip=209.85.210.173 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="n9xlYiM5" Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-82d0b68837aso4403445b3a.2 for ; Thu, 23 Apr 2026 09:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776962567; x=1777567367; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=u+QkA1oAtbdwJWVoHl2LBARGYjytOFHnCUJvD5+AJyw=; b=n9xlYiM5Ym47Db1bji4ldasZ+Dwn+yGZljT6ZVbVhYfApOIvnCejVKAa1zSUCVLjkU WA0AYVDHsNB+6Hams75CNhN6Lgr2JlWR70ZVzouyzZcCfzIzTl+DYCsK6PpmkpLh6G00 jo6kESbfgXHJuz6plVeWFpm6suniLaEGwiKb/st8eImAQHAiwxzRC4E18R2Y4l9HPU/I ZOKh+LHQrmLRR12Nl291M37Gn6TAsMh1PIvSDt7ecBRXakMf/+9JSfc0Z0Wy58gqKOIT yQp3R4jE9Eq/Z5LuqkL4v8bLL/9EFEZaC3/xxpnQKl7iGs6xYJdLxSFGbToNB2vBzvr+ pjMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776962567; x=1777567367; h=in-reply-to:content-transfer-encoding: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=u+QkA1oAtbdwJWVoHl2LBARGYjytOFHnCUJvD5+AJyw=; b=PWxTAxGshor2FQjflo/UL/YmR/vcPenLQkdCWFGZc6l0GZea/iJHSy5Uj62DCR+NZi sPyxMFrCJ6m5kS2phMWGgmgaNMk0e1+Rfu9hUC0/KVv3IDs5eCLGnUJSOxSUGk9gpZTj Sg0aXcO1WgBIQpD7BbXYgxk7f8YRp7I0RSUCDmHDXvZzW4ZpSzy5j44/PGtsYqTpCK6Q iUYVHACaNBh67LcSk31wgHWlpixXnUPNvgPC86AkPqQh/K51ir5r55xozP/MMp0sz41H lslCanBEyz3ibl4aEYysvN7EuprzstNAjfgktW0fGTpXHEpQxXN5pQG5pxAhPn5zs25a ZzjQ== X-Forwarded-Encrypted: i=1; AFNElJ+hfeKLDwoGa9rN5oDCpqr2CNyDokGJZwJbsr5TVKOHIGVLyDrVhXIPj2Ch33V3gYGmgfM6y1o5MXaCezs=@vger.kernel.org X-Gm-Message-State: AOJu0YzNQL4esio95qM96IiTULGLtPlB6XvpKYU30V+IDvrLDOrg9b6E h4D2ujmZyKHO5Y3cIvuJ4G9LSrm6bTVu/KKybdktaGVJRVtx0g1z6bBg X-Gm-Gg: AeBDiesU52t74qTJ+HtqjkY6dqNe5IQHixJcw4V/kde+D2YbJDtbOkV22uoDGjmIUHJ oZapShbhPP04R0RdG+veE5zDvGkUWXaFV/ApUKNO2JA6WhlD99EJLsu4gESm/QfDK9RCHy4fxRH WIQNu5k0VSbtlUliOoX5yrV9c7Re+TYNxdHRxji2lMafZmYboPo7TV5o38J+e/LZJnmKSeSnAgG ZDI5nuHUL1qfJYQifp7qmEl7OPTSfCXPyLD22NXHpu2LsG24xACQmEgJwaVREI4V0I30eTaYvMi E3XZF04owijAURorc2BCrP2SHUl3WQ68L2temBWZQ4sfMjc9MQDifxvYeIUF/9QqqNj75bIRF3B kBqM4fo6TqlI9cNCFWnl1KDEIC9TbTdvpQtO9K/Ks5vzBvtRjp6wDE4M3O4JbaAlpHAKbF7qZ7d ccffxbvpdXv6ZoTG14rk0KQIc8jyzY1PQ50Z72KYl0CQsZHMLrq3Qr7bN372BekBxk/gejWA== X-Received: by 2002:a05:6a00:aa08:b0:82f:b0:28f0 with SMTP id d2e1a72fcca58-82f8c8e5120mr31598227b3a.34.1776962567316; Thu, 23 Apr 2026 09:42:47 -0700 (PDT) Received: from KASONG-MC4 ([101.32.222.185]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82f8ea09914sm20341382b3a.26.2026.04.23.09.42.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 09:42:46 -0700 (PDT) Date: Fri, 24 Apr 2026 00:42:37 +0800 From: Kairui Song To: Barry Song 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 , 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, Qi Zheng , Baolin Wang Subject: Re: [PATCH v5 04/14] mm/mglru: restructure the reclaim loop Message-ID: References: <20260413-mglru-reclaim-v5-0-8eaeacbddc44@tencent.com> <20260413-mglru-reclaim-v5-4-8eaeacbddc44@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Apr 16, 2026 at 02:33:48PM +0800, Barry Song wrote: > On Mon, Apr 13, 2026 at 12:48 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, the scan number is only shifted by reclaim priority when > > aging is not needed or when 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 aging and offline memcg reclaim works: > > Previously, aging was always skipped at DEF_PRIORITY even when > > eviction was impossible. Now, aging is always triggered when it > > is necessary to make progress. The old behavior may waste a reclaim > > iteration only to escalate priority, potentially causing over-reclaim > > of slab and breaking reclaim balance in multi-cgroup setups. > > > > Similar for offline memcg. 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 seems > > correct. 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 with reparenting. > > > > And while at it, make it clear that unevictable memcg will get rotated > > so following reclaim will more likely to skip them, as a optimization. > > And apply a minimal batch factor when reclaim is running with higher > > priority. > > > > Overall, the memcg LRU rotation, as described in mmzone.h, > > remains the same. > > > > Reviewed-by: Axel Rasmussen > > Signed-off-by: Kairui Song > > --- > > mm/vmscan.c | 72 +++++++++++++++++++++++++++++++++---------------------------- > > 1 file changed, 39 insertions(+), 33 deletions(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 963362523782..d4aaaa62056d 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -4913,49 +4913,41 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec, > > } > > > > static bool should_run_aging(struct lruvec *lruvec, unsigned long max_seq, > > - int swappiness, unsigned long *nr_to_scan) > > + struct scan_control *sc, int swappiness) > > { > > DEFINE_MIN_SEQ(lruvec); > > > > - *nr_to_scan = 0; > > /* have to run aging, since eviction is not possible anymore */ > > if (evictable_min_seq(min_seq, swappiness) + MIN_NR_GENS > max_seq) > > return true; > > > > - *nr_to_scan = lruvec_evictable_size(lruvec, swappiness); > > + /* try to get away with not aging at the default priority */ > > Not a native speaker, and I’ve been struggling a bit with this sentence. > Does it mean “try to avoid aging at the default priority”? Yes, good suggestion. Let me update this comment while at it then. > > + if (sc->priority == DEF_PRIORITY) > > + return false; > > > "This slightly changes how aging and offline memcg reclaim works: > > Previously, aging was always skipped at DEF_PRIORITY even when > eviction was impossible. Now, aging is always triggered when it > is necessary to make progress." > > It seems clear that you are returning false for DEF_PRIORITY. > How should I understand “aging is always triggered”? It can return true above. But yeah, my commit message can be improved. Will slightly update it. > > +/* > > + * For future optimizations: > > + * 1. Defer try_to_inc_max_seq() to workqueues to reduce latency for memcg > > + * reclaim. > > + */ > > static bool try_to_shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc) > > { > > + bool need_rotate = false; > > long nr_batch, nr_to_scan; > > - unsigned long scanned = 0; > > int swappiness = get_swappiness(lruvec, sc); > > + struct mem_cgroup *memcg = lruvec_memcg(lruvec); > > + > > + nr_to_scan = get_nr_to_scan(lruvec, sc, memcg, swappiness); > > + if (!nr_to_scan) > > + need_rotate = true; > > > > - while (true) { > > + while (nr_to_scan > 0) { > > int delta; > > + DEFINE_MAX_SEQ(lruvec); > > > > - nr_to_scan = get_nr_to_scan(lruvec, sc, swappiness); > > - if (nr_to_scan <= 0) > > + if (mem_cgroup_below_min(sc->target_mem_cgroup, memcg)) { > > + need_rotate = true; > > break; > > + } > > + > > + if (should_run_aging(lruvec, max_seq, sc, swappiness)) { > > + if (try_to_inc_max_seq(lruvec, max_seq, swappiness, false)) > > Could we move the original comment here: > /* stop scanning this lruvec as it's low on cold folios */ In a later commit we will drop the "stop scanning" behavior, but I can keep the comment for now indeed. Thanks for the review.