From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) (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 129FA285C91 for ; Thu, 28 May 2026 14:02:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779976931; cv=none; b=uCje5aUlruP3VMigVzDkMT/FDbB22uoKHwJfCm9nKEvp9Fut8SqGA5CkywHdCiJ+HWzQVqrB4AcEf2CoCTSBd5MDgvWerNHZXon9EBA56P+LLfB1vAlIYFWzcKfwhGPHkdyQ35E5SrEx/g6weMS4ThkNA0LFx6Q5gaT81nWJKAg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779976931; c=relaxed/simple; bh=faBJi79lTUhe/bRv39kjceYaSpZ5zHVs021AOV1s3Gs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SAzJsXYsWc9c1MdVuhA6Qv3XXfznFBp0T8SYJPIgzjwsPPcqx5wEawNQJEICIBkOtAuSJvqa3WJJ+v9WqB23DZIzlrmPb9+t6x7XHzTz398Q3JT1NqhnsRD5cakU9xvAZpwntq5HcQk3GbBFi7Zi2oH3v3vmli0jtv7kC7qgQik= 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=FXQrgfAf; arc=none smtp.client-ip=209.85.160.180 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="FXQrgfAf" Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-51306c9f2e1so148788061cf.0 for ; Thu, 28 May 2026 07:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg.org; s=google; t=1779976928; x=1780581728; 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=VWqHhRZrJdYq3LgBVddMXMAngLR9XNgV7phzSAMcWeM=; b=FXQrgfAf3NsAbsJZLxYe112lBDZucLsMtM9Y+JJ8hDxuTkzkoqw3f+f80dHjDfj3hg E8qk2af7OoRJtpyUjDoEwzFix3C0fOE2G1slRNApX6KSoMZ/GcoGRA+BHVIKvVltHdgl s/aXkvLUSzXRE+Seu/d6G8j1RNorTbd5jtNvrmjmHXj+XgQrRaMfOyfHnbiVQyD8tuW0 vwQ7G3Fan/togazXd6FrS/UzZzle2p0dZG7tHXMzCj4ulGUq3x8p8VEnLlPExJjhaY9D HhPLhtKWurDBP1WX7Eu91d9LLZlDJ0tNu98RXqLcJ+jJUtfsEcYZ1JMb91vlAvcF0E+L qlSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779976928; x=1780581728; 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=VWqHhRZrJdYq3LgBVddMXMAngLR9XNgV7phzSAMcWeM=; b=sOtO4/eQNZ3uxBfK6qxCWyGiFXhu9x6m7kCu6JWJVIdp0G25zMO2pErt/97Tj47x32 Y6uiVvWnnRbBOwtb0Txafr2qPF5xuinfHI2oHhw+ZVUKqNnfR0eParoxWbRNryFtg1G4 05LooMOr9NFwb/yST53BhpMNxXaEHFuF2YSWe1seMmMwcEPbgoml3hIc7hqIbgWsiU7G vuH2Kl7TgmVj37XR1llAhtR2VPYN7+Dpc42WWzQcSbrLiBNSYoev6WxlT0OL16DreXWD g+2RYNAAUaONHbqlUd85345EeeaUtq7YsdH/ZjOd88Qt4OhkherjckqKxrh4+Jsj/h19 Zpfw== X-Forwarded-Encrypted: i=1; AFNElJ8V48A8Jv+WVI8+TaOAh1JKIXL71fWtEgyYygkkUoz35LbK2/yTX4UwYyk7AAo/TWL0XZKV+WWj4U+Xz1M=@vger.kernel.org X-Gm-Message-State: AOJu0YyXo245HiS0jQDhTHoae0+GiYLBLdpTgC4iZrzbTgcbyJG0etwq Tu5fk+z51RmoEwCVtH0+kSxq8M0wq6Ine5/v5xHoSqqThPVE0iVqHYJKomiyotGPngY= X-Gm-Gg: Acq92OHVyjsCMxFuXHXXCRX5xVR8h4M3zFPqmbzSn/rQjLG1fT+NkLZegxCe9BRYgfa WB6eqhcfyVVKSAGcdjern4s3jT2pPNvwlwdkNWBzr+dyeD0TBNG0y0RAVxikeePfF+l7IzDhj0Y WVS3aWyjSDHVCZgLYe4pbi30Ojo2LYZp8Elr2ARt5Z424jViFTF7KTWD2Bd53LZsIEG/IBDGzcx EeVB9MiX/3VbOapS5kCxOyyctTAhoRLi4hd8nYiv5y4cN0RWgkC16riOGc+CPL/Jlv9xfEimhth 8PwNzRoBeMhacxK4lGZvCicZiZ6wx/I2C8ZuHMG7vCtWcDfCNiFbz99nHVUAKMgHDWyFby4DwyQ z4Jx7KVOoaD/CtlicrY7LZKql7y4SJJg1ecvF2Ryh3q1gyyvIrToG7S6cnxoFD+lJJQ== X-Received: by 2002:a05:622a:a6da:b0:50f:9c33:af18 with SMTP id d75a77b69052e-516d4428303mr295741211cf.51.1779976927300; Thu, 28 May 2026 07:02:07 -0700 (PDT) Received: from localhost ([2603:7001:f100:500:365a:60ff:fe62:ff29]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-51706b066e5sm72303461cf.26.2026.05.28.07.02.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2026 07:02:05 -0700 (PDT) Date: Thu, 28 May 2026 10:02:04 -0400 From: Johannes Weiner To: Usama Arif Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Shakeel Butt , Michal Hocko , Dave Chinner , Roman Gushchin , Muchun Song , Qi Zheng , Yosry Ahmed , Zi Yan , "Liam R . Howlett" , Kiryl Shutsemau , Vlastimil Babka , Kairui Song , Mikhail Zaslonko , Vasily Gorbik , Baolin Wang , Barry Song , Dev Jain , Lance Yang , Nico Pache , Ryan Roberts , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 9/9] mm: switch deferred split shrinker to list_lru Message-ID: References: <20260527204757.2544958-1-hannes@cmpxchg.org> <20260527204757.2544958-10-hannes@cmpxchg.org> <6f9c78b2-3846-4f75-bcc2-41bf91230513@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: <6f9c78b2-3846-4f75-bcc2-41bf91230513@linux.dev> On Thu, May 28, 2026 at 02:32:06PM +0100, Usama Arif wrote: > > > On 27/05/2026 21:45, Johannes Weiner wrote: > > The deferred split queue handles cgroups in a suboptimal fashion. The > > queue is per-NUMA node or per-cgroup, not the intersection. That means > > on a cgrouped system, a node-restricted allocation entering reclaim > > can end up splitting large pages on other nodes: > > > > alloc/unmap > > deferred_split_folio() > > list_add_tail(memcg->split_queue) > > set_shrinker_bit(memcg, node, deferred_shrinker_id) > > > > for_each_zone_zonelist_nodemask(restricted_nodes) > > mem_cgroup_iter() > > shrink_slab(node, memcg) > > shrink_slab_memcg(node, memcg) > > if test_shrinker_bit(memcg, node, deferred_shrinker_id) > > deferred_split_scan() > > walks memcg->split_queue > > > > The shrinker bit adds an imperfect guard rail. As soon as the cgroup > > has a single large page on the node of interest, all large pages owned > > by that memcg, including those on other nodes, will be split. > > > > list_lru properly sets up per-node, per-cgroup lists. As a bonus, it > > streamlines a lot of the list operations and reclaim walks. It's used > > widely by other major shrinkers already. Convert the deferred split > > queue as well. > > > > The list_lru per-memcg heads are instantiated on demand when the first > > object of interest is allocated for a cgroup, by calling > > folio_memcg_alloc_deferred(). Add calls to where splittable pages are > > created: anon faults, swapin faults, khugepaged collapse. > > > > These calls create all possible node heads for the cgroup at once, so > > the migration code (between nodes) doesn't need any special care. > > > > Reported-by: Mikhail Zaslonko > > Tested-by: Mikhail Zaslonko > > Acked-by: Shakeel Butt > > Reviewed-by: Lorenzo Stoakes (Oracle) > > Signed-off-by: Johannes Weiner > > --- > > include/linux/huge_mm.h | 7 +- > > include/linux/memcontrol.h | 4 - > > include/linux/mmzone.h | 12 -- > > mm/huge_memory.c | 364 +++++++++++++------------------------ > > mm/internal.h | 2 +- > > mm/khugepaged.c | 5 + > > mm/memcontrol.c | 12 +- > > mm/memory.c | 4 + > > mm/mm_init.c | 15 -- > > mm/swap_state.c | 10 + > > 10 files changed, 150 insertions(+), 285 deletions(-) > > > > [...] > > > diff --git a/mm/memory.c b/mm/memory.c > > index 135f5c0f57bd..f22e61d8c8de 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -5222,6 +5222,10 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf) > > folio_put(folio); > > goto next; > > } > > + if (order > 1 && folio_memcg_alloc_deferred(folio)) { > > + folio_put(folio); > > Ah sorry, should have caught this in the previous version, do we need > > count_mthp_stat(order, MTHP_STAT_ANON_FAULT_FALLBACK); > > here? This isn't an allocation we expect to fail with any sort of routine that we'd need to capture it in the event counter. It would warn in dmesg if it did. But in practice it can't happen at all, since it's a sub-costly-order slab allocation and the allocator would loop and OOM kill stuff until it succeeds. > or maybe we just goto next instead of goto fallback and trty next > viable order? Again I don't think it matters, but fallback seems a bit more correct because the size of the list_lru allocation doesn't change with lower orders (until we hit 0). So I think we can just leave it as is.