From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3AE3DC71136 for ; Tue, 17 Jun 2025 17:52:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C53E66B00A1; Tue, 17 Jun 2025 13:52:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C27E46B00A3; Tue, 17 Jun 2025 13:52:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B652E6B00A4; Tue, 17 Jun 2025 13:52:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A64B36B00A1 for ; Tue, 17 Jun 2025 13:52:05 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1C619160938 for ; Tue, 17 Jun 2025 17:52:05 +0000 (UTC) X-FDA: 83565636210.20.6990B49 Received: from out-186.mta1.migadu.com (out-186.mta1.migadu.com [95.215.58.186]) by imf13.hostedemail.com (Postfix) with ESMTP id 1B4A82000E for ; Tue, 17 Jun 2025 17:52:02 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=JaadzyNh; spf=pass (imf13.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.186 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750182723; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9H/iaRf40PeLw7FvouwIQ5qs9ZEfzW9xC+JE7Z9klJ8=; b=UwzWx2v/GjzOoVM9FaB+lx6I5A1SIkbvZBv2/egFLpuW2h4kmoII4iE7KgS05XIyHrI3GF 75TCioNXVsAvmSYWK1lGSNN2B8HSGZpVMwXyp3t4YYiscUQCl5kDFsIPA4oEe+KYWOMuoD Jd4TP9ziMLss8Xw8Lk+BKdVnX/Bzib0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750182723; a=rsa-sha256; cv=none; b=tljC793iSzjZ7t4NcyBm7a6ZgBVaU19uvI+2oRLjuuVyIlbc77aDJ7G/MfBGV+Va3AI4jh s1TNI/7hbopUex5Lb9YxpJJqB8qW0Omd5PAqeCWj8zdhhfdziIx72gNKJVjnrL30saYRy0 2g330dxzEHxQZa2zUy72wcvXK4CQi8k= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=JaadzyNh; spf=pass (imf13.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.186 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Tue, 17 Jun 2025 10:51:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1750182720; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9H/iaRf40PeLw7FvouwIQ5qs9ZEfzW9xC+JE7Z9klJ8=; b=JaadzyNhevveq+vZ8dIcdKKaPKuCecNr0d21VLID7tFlRNIz64VPIzWilCmDsaOsZS71DG 1wer4h9Yc7RXamq/su+Jb4DBgzcAsUg30BK6pQHRS2KNWJ+Ec9rT9eWJylV/z3nUk4AbTJ XloVox0tXwOQJilPwqMg882PpK30gCI= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Lorenzo Stoakes Cc: David Hildenbrand , Andrew Morton , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section Message-ID: References: <20250616203844.566056-1-lorenzo.stoakes@oracle.com> <727b5e89-89d7-4abf-a93c-8d6f2cb2c438@redhat.com> <35kubwcjkvyu34k7ejp2ykydtrbcl2gptcurs7rhqzi3cy3l5h@gcxndb7dfdgq> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 1B4A82000E X-Stat-Signature: fr3g44cu1ey75ar47m3fdbzh817rh3c1 X-Rspam-User: X-HE-Tag: 1750182722-22338 X-HE-Meta: U2FsdGVkX19uwh/E5aULXXnUE8Gf5Jm/ZPmZCVmw9O8Jawythr6eBRHvZNL3TAs5jG6w8fLlfivY8of0j66SFtnDNx8hwOFgoNyCyYoheEAb2Mc0sKKe61Oeell6wRUVceztfNZxP5pUM0iOWpqOkseI9ogFcR2Jll0gRjcV9qajpdhufGleaeoWS4GMhP4gHg9H0mrSPlZjNVSQN2d4aR0PeQQa65Snpkfaa25v7PXFbygTZX6qeuzkCsTijoh2m1FEt+IjV+vkdyr2FwrmMpZE4llaAQhtDRf1jYWbY/dhF1ENDBRUfKDrO3MwFRa0nDKBkmyJEHuZZGqHOdEnb2nYetcBglva9lKb6dsy2UOSpFeqrTeyR1R3p100fGIMVSNJlLGahkmnD7UuabCEsZ405sycs2htawXhKAo6KVCFQuvn9+ZhXRuHOsd1OdpvXufueqPeBW7URGXuM99un772/YPvgFeLY+hzQtYZ/Dg5PNRFiZ3fWCHj6+NXAnS99H/2KyK7c947TftU+SkO56r13lTOEtPw4W3//eP2F8BBvehxzdaUvihTRm7lxBFUzh1vlaQ753InfLb4NqcxCNkP8njE39oAmnADULeZGow/OQzMt1wNJ46BUY0dUGnzDHOVb2sbSIw4e6zL1ttrUwu5ntJ/UPM1a0AylPqyTTKFP1cvL6dQe0HzO2Z1Wi0PQgZkgezvYcSszvx/avzJltDC4DdG5qeKho/L0pj+AIGPJvmc2Qe89rpYABlKZIwTm0gNaj0ipc03ZUjY0PrQNzD/wqd6kSeQ2fIK29DodqclbXqCxfxW1Q+37bN+JwN0bJotTuabKe4S6zK2YFgWqvvpY1QvnTK1hUl5yBxUGKIFUhnBhVikyw+AnTG/zLEcAgYthyVmYHwCxx3QLXXsvc2EHs2/u2LbOnuaqfFRug+vXr2xj3ZNnRBoWW4IhwKTcFILoC6X2mdQe68aqXY rm98OOo+ n/wJSE8NkeXGUHIVUwJ2DgV524/K/cgR1aKrqiJjgti3XdnGEZ19B73I8DBLvO1VLhVJ3dE4tyVXL3JF+Xd8E5s9YXLoVUruwV9RPIreTWaR8iVUhU7zsYFLGpjrCpbzgpOeVOCXCXyU72eDZaOOxUGTJRo9O3yZhkuoo23gbbECWtdD768HKAzpY+UqecIa7njvY7MnwE6rvlDo7ATumpcIbjiY38izSUu1kAckoHsfYWEEbMqeWMr8NJGFQsRMvAbQlsoW5mNhM3Nh9VgmUx0I+PKDqtYhuH+OTTLzjNKd6S6wLXeYyTO/8PvejIUDhRf4m X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jun 17, 2025 at 04:22:33PM +0100, Lorenzo Stoakes wrote: > On Mon, Jun 16, 2025 at 03:56:02PM -0700, Shakeel Butt wrote: > > On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote: > > > On 16.06.25 22:38, Lorenzo Stoakes wrote: > > > > There are a number of files which don't quite belong anywhere else, so > > > > place them in the core section. If we determine in future they belong > > > > elsewhere we can update incrementally but it is preferable that we assign > > > > each file to a section as best we can. > > > > > > > > Signed-off-by: Lorenzo Stoakes > > > > --- > > > > REVIEWERS - let me know if these seem appropriate, I'm eyeballing > > > > this. even if they are not quite best placed a 'best effort' is still > > > > worthwhile so we establish a place to put all mm files, we can always > > > > incrementally update these later. > > > > > > > > MAINTAINERS | 28 ++++++++++++++++++++++++---- > > > > 1 file changed, 24 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > index 4523a6409186..a61d56bd7aa4 100644 > > > > --- a/MAINTAINERS > > > > +++ b/MAINTAINERS > > > > @@ -15740,10 +15740,6 @@ F: include/linux/memory_hotplug.h > > > > F: include/linux/memory-tiers.h > > > > F: include/linux/mempolicy.h > > > > F: include/linux/mempool.h > > > > -F: include/linux/memremap.h > > > > -F: include/linux/mmzone.h > > > > -F: include/linux/mmu_notifier.h > > > > -F: include/linux/pagewalk.h > > > > F: include/trace/events/ksm.h > > > > F: mm/ > > > > F: tools/mm/ > > > > > > Probably better to have some section than none ... was just briefly > > > wondering if "CORE" is the right section for some of that. Some of that > > > might be better of in a "MM MISC" section, maybe. > > > > > > > @@ -15764,16 +15760,40 @@ S: Maintained > > > > W: http://www.linux-mm.org > > > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm > > > > F: include/linux/memory.h > > > > +F: include/linux/memremap.h > > > > F: include/linux/mm.h > > > > F: include/linux/mm_*.h > > > > F: include/linux/mmdebug.h > > > > +F: include/linux/mmu_notifier.h > > > > +F: include/linux/mmzone.h > > > > F: include/linux/pagewalk.h > > > > F: kernel/fork.c > > > > F: mm/Kconfig > > > > F: mm/debug.c > > > > +F: mm/debug_page_ref.c > > > > +F: mm/debug_vm_pgtable.c > > > > > > Wondering if there should be a MM DEBUG section. But then, no idea who in > > > their right mind would be willing to maintain that ;) > > > > > > > +F: mm/folio-compat.c > > > > +F: mm/highmem.c > > > > F: mm/init-mm.c > > > > +F: mm/internal.h > > > > +F: mm/interval_tree.c > > > > +F: mm/io-mapping.c> +F: mm/ioremap.c > > > > +F: mm/list_lru.c > > > > > > Smells like reclaim/memcg. > > > > Shrinker might be more appropriate (along with the list_lru.h) > > Yeah I struggled with this one. It's a weird one, it's like a generic LRU > algorithm: > > zswap_lru_add() > binder_lru_freelist_add() > -> list_lru_add() > > Also called internally by list_lru_add_obj() which is used for dentry LRUs by a > number of filesystems > > But also by the working set code in workingset_update_node() :) > > So it's a bit all over the place. > > I wonder whether best for mm misc as a result? list_lru is the data structure / abstraction to interact with the shrinker. Kernel components which can consume large amount of kernel memory and has a way to drop some on memory pressure (e.g. some form of cache) register themselves with the shrinker and list_lru is used to store/link their internal objects which the shrinker can drop/reclaim during memory reclaim.