From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f173.google.com (mail-qk1-f173.google.com [209.85.222.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 9291C23A9B0 for ; Thu, 18 Dec 2025 13:32:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766064775; cv=none; b=fpVG+qV2o7n55HJeS76W5+q3x4TNxIUeaoK2GUVw7E/3BEd6Nv5wRnqdfa2S2s8e4XuoJhOmXhwmIZFqTFKn0382ZxnWLLBjiJkH9rpcAsJt37K12gA7Rdahu0egg0WrlJKSqYwjwqiM0VzwmKiyWHbP8oKQU1QoYQTZl5mUpds= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766064775; c=relaxed/simple; bh=YGEoRnWIgYwcYRWzBC1zSuyhYRERcXNcHvF3xnGn85k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oPY3+4Xn0bGgJpmJ/4BW3z4C/zYoVzkIaFN8U6bcdv2/UKZQ0G9d7GjRdS3CY2gD0/neeoLygF/awqj3h6cxsG0uw5lRhmUPxc6E7ZWJU6RpYwwi0LxfIkdulDxi3onRXUiTT8IDuSbtF5EYPlWUBRWYl6DT4J8njqPw1vLGXWw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org; spf=pass smtp.mailfrom=cmpxchg.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b=jmGBdzjW; arc=none smtp.client-ip=209.85.222.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cmpxchg.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg.org header.i=@cmpxchg.org header.b="jmGBdzjW" Received: by mail-qk1-f173.google.com with SMTP id af79cd13be357-8b2148ca40eso93297485a.1 for ; Thu, 18 Dec 2025 05:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1766064770; x=1766669570; 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=ZQWA//U94w+RfVBDi+XEBJcp+dqWUOXxb8pArjVqn04=; b=jmGBdzjWGbml5DSAjuSTWqpaDoyS91gMnkK7tfC9lx1VnqtdwNWV81idyPXpCQZ9wL qBSuDrPZBvFQEiOGQQXyjQR2+4qHLCqtmkq/w2Kw73Xao3ZcGJZbWfyw+twYJiljLKPQ NFv7QbDVqSF2VF7r4IvNDQF9BByRedEQk4TvdxrbB9lsb0cgF/KOgnzCDxiqApPKpvqq wkjmEkfmUANys4VB9AhNgxPVqHddB7QFqfyOFS4/XzhwngMUxCY/9Daq7qu+BgJqTn9p 3ON4M/p4l7bv4AtSB7NFDNQCbzdJi1at87nK/Up0Bn6f+X4XAFeYP9o2mk6BtO7X+kjd pbUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766064770; x=1766669570; 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=ZQWA//U94w+RfVBDi+XEBJcp+dqWUOXxb8pArjVqn04=; b=r5QE4U3Y/S9+X187YRgZ6j/Cfli/x3OujfFkRYAIZXoRv7R/hIwaqmU4LyAmUClHKS 9pR4gKYMUr/hKBLHxTS7ZSAIhS1XjixlHpKiJjqUMNXrtqrqU9ZwNVIuHJrO/kzB5Fva I2qlWdqXCCq33UipyKV3WMDl4I9Zo7wZXCMaMz1m23Q4JdHoqggox8C/s3pbAp3zbn1a 1w7GvlKIQ/J5NMUs6o4JkUt2lhbQ5tx488TQAgc03AnONBjVg+XwF5gm+IqWDjE7YYKg tWZot5yIOgsUteuU0mkL7KdnpvxWlqgADboAxJyawd0KiDgPpeRtsp0gnsMCpjU1HtVA RZWA== X-Forwarded-Encrypted: i=1; AJvYcCXN3yp7HHoOtibEOd89SMPVcQZrb39lZMIBKTNh1+/iFHjgdMK4KYPImHXQg3bn/IfzrYtcIfl3YidKajc=@vger.kernel.org X-Gm-Message-State: AOJu0YzW26ceJbS4DdFW5uSkOeHnPLNvbyk546olsZeZvpOY+ss7Jui2 ihcUo9obwuLWhEvldqf8VaYXG0QtfkbRbdITTvZeeKwo55DbMgz+MIKXXrGY/M/4bm4= X-Gm-Gg: AY/fxX5TQNFHAStdGnsRTmChD7onrGuq8kTrgXaDoPHoM4liO7ciqV/w9C+gseRQ7bF XyazkIU/Xtad5s9hMo6GfqOoMf6oc0pxLA7T34/4N2+fO3TwuUulcXTFw1Hk/wTfssPsSGfHUuM aeL43kdjMtXr7/EK3BEkGt2ayR+pfrFCAn5IxdER9C52fpshf5be3oZ7IK/nuz2hyXMXkPAj7Mt 0InJOwwLmyzDNAK9MAqfKQRHMsNMv1NdpADTmlS1g84qi556Mon8ZaFnnN1YSQHezfcvNJnvUW5 rsdA/QURiRAJNa3b3ouhB2FdWP2cOvSRNdnu3lGHIlKZ6Kix8Vpninap1K2siE5pOMhir/WHtxh DI706+1fSugUSPl/kwgXYjuL494wpBwnuY4ap59Ol9j1xdo6vLuiUHPx5LaXc8pDYWGUrQGLUDN jLZ8NimDOS0w== X-Google-Smtp-Source: AGHT+IH3FUksskKCGR1DNGkk10snBCU32vYx1Rd56tm0XXUZfGBDWgz7+GVVqCXyzIf14zAp0WBPFg== X-Received: by 2002:a05:620a:319d:b0:8b2:74e5:b11 with SMTP id af79cd13be357-8bb3a39c0d7mr3122332685a.82.1766064769594; Thu, 18 Dec 2025 05:32:49 -0800 (PST) Received: from localhost ([2603:7000:c01:2716:929a:4aff:fe16:c778]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8beeb5d5fb7sm170608885a.7.2025.12.18.05.32.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Dec 2025 05:32:48 -0800 (PST) Date: Thu, 18 Dec 2025 08:32:45 -0500 From: Johannes Weiner To: Qi Zheng Cc: hughd@google.com, mhocko@suse.com, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, david@kernel.org, lorenzo.stoakes@oracle.com, ziy@nvidia.com, harry.yoo@oracle.com, imran.f.khan@oracle.com, kamalesh.babulal@oracle.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, chenridong@huaweicloud.com, mkoutny@suse.com, akpm@linux-foundation.org, hamzamahfooz@linux.microsoft.com, apais@linux.microsoft.com, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Qi Zheng Subject: Re: [PATCH v2 24/28] mm: vmscan: prepare for reparenting traditional LRU folios Message-ID: References: <800faf905149ee1e1699d9fd319842550d343f43.1765956026.git.zhengqi.arch@bytedance.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: <800faf905149ee1e1699d9fd319842550d343f43.1765956026.git.zhengqi.arch@bytedance.com> On Wed, Dec 17, 2025 at 03:27:48PM +0800, Qi Zheng wrote: > From: Qi Zheng > > To reslove the dying memcg issue, we need to reparent LRU folios of child resolve > memcg to its parent memcg. For traditional LRU list, each lruvec of every > memcg comprises four LRU lists. Due to the symmetry of the LRU lists, it > is feasible to transfer the LRU lists from a memcg to its parent memcg > during the reparenting process. > > This commit implements the specific function, which will be used during > the reparenting process. > > Signed-off-by: Qi Zheng > Reviewed-by: Harry Yoo Overall looks sane to me. I have a few nits below, not nothing major. With those resolved, please feel free to add Acked-by: Johannes Weiner > @@ -2648,6 +2648,44 @@ static bool can_age_anon_pages(struct lruvec *lruvec, > lruvec_memcg(lruvec)); > } > > +#ifdef CONFIG_MEMCG > +static void lruvec_reparent_lru(struct lruvec *src, struct lruvec *dst, > + enum lru_list lru) > +{ > + int zid; > + struct mem_cgroup_per_node *mz_src, *mz_dst; > + > + mz_src = container_of(src, struct mem_cgroup_per_node, lruvec); > + mz_dst = container_of(dst, struct mem_cgroup_per_node, lruvec); > + > + if (lru != LRU_UNEVICTABLE) > + list_splice_tail_init(&src->lists[lru], &dst->lists[lru]); > + > + for (zid = 0; zid < MAX_NR_ZONES; zid++) { > + mz_dst->lru_zone_size[zid][lru] += mz_src->lru_zone_size[zid][lru]; > + mz_src->lru_zone_size[zid][lru] = 0; > + } > +} > + > +void lru_reparent_memcg(struct mem_cgroup *src, struct mem_cgroup *dst) I can see why you want to pass both src and dst for convenience, but it makes the API look a lot more generic than it is. It can only safely move LRUs from a cgroup to its parent. As such, I'd slightly prefer only passing one pointer and doing the parent lookup internally. It's dealer's choice. However, if you'd like to keep both pointers for a centralized lookup, can you please rename the parameters @child and @parent, and add VM_WARN_ON(parent != parent_mem_cgroup(child)); Also please add a comment explaining the expected caller locking. Lastly, vmscan.c is the reclaim policy. Mechanical LRU shuffling like this is better placed in mm/swap.c.