MAINTAINERS | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
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 <lorenzo.stoakes@oracle.com>
---
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/
@@ -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
+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
+F: mm/maccess.c
+F: mm/mapping_dirty_helpers.c
F: mm/memory.c
+F: mm/memremap.c
+F: mm/mmu_notifier.c
+F: mm/mmzone.c
+F: mm/oom_kill.c
+F: mm/page_idle.c
F: mm/pagewalk.c
+F: mm/pgtable-generic.c
+F: mm/process_vm_access.c
+F: mm/ptdump.c
+F: mm/sparse-vmemmap.c
+F: mm/sparse.c
F: mm/util.c
MEMORY MANAGEMENT - EXECMEM
--
2.49.0On 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 <lorenzo.stoakes@oracle.com> > --- > 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. > +F: mm/maccess.c > +F: mm/mapping_dirty_helpers.c > F: mm/memory.c> +F: mm/memremap.c memory hotplug related. Well, one could argue that it's just a memory hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be worth a separate section ... > +F: mm/mmu_notifier.c > +F: mm/mmzone.c > +F: mm/oom_kill.c This contains quite some meat. I wonder if a OOM section would be appropriate (Michal, I'm looking at you :) ) -- Cheers, David / dhildenb
On 6/16/25 23:10, 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 <lorenzo.stoakes@oracle.com> >> --- >> 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. >> @@ -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 ;) Guess I'm not in my right mind, but I'd be fine with that. Although most of my experience is with page_owner and debug_pagealloc which are tied to the page allocator. And I think it's better when these debug files are in the section of the functionality they debug. mm/debug_page_ref.c could probably go to the page allocator. mm/debug_vm_pgtable.c is maybe related to pagewalk? (it could be redone to a kunit test, btw?). Only mm/debug.c seems a mix of stuff related to various mm parts... maybe could stay in core then.
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 <lorenzo.stoakes@oracle.com> > > --- > > 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. Responded in thread elsewhere on this but yes defo! > > > @@ -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 ;) Thanks for volunteering! :P Yeah I did think about this. But given the above it's maybe better to put in mm misc until we a brave soul steps up? :) I have a few other new sections that are possibly ones we should add: CMA DMA pool statistics (e.g. vmpressure.c, vmstat.c) But these could go to misc for the time being also. Of these 3 possibly statistics is the one that makes the best case I think. > > > +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. > > > +F: mm/maccess.c > > +F: mm/mapping_dirty_helpers.c > > F: mm/memory.c >+F: mm/memremap.c > > memory hotplug related. Well, one could argue that it's just a memory > hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be > worth a separate section ... Hm not sure? Again maybe best for misc for now until we decide :) > > > +F: mm/mmu_notifier.c > > +F: mm/mmzone.c > > +F: mm/oom_kill.c > > This contains quite some meat. I wonder if a OOM section would be > appropriate (Michal, I'm looking at you :) ) As Shakeel points out that's already done (see [0]). [0]: https://lore.kernel.org/linux-mm/20250617085819.355838-1-mhocko@kernel.org/ > > > -- > Cheers, > > David / dhildenb >
On Tue, Jun 17, 2025 at 04:26:42PM +0100, Lorenzo Stoakes 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 <lorenzo.stoakes@oracle.com> > > > --- > > > 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. > > Responded in thread elsewhere on this but yes defo! > > > > > > @@ -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 ;) > > Thanks for volunteering! :P > > Yeah I did think about this. But given the above it's maybe better to put in mm > misc until we a brave soul steps up? :) > > I have a few other new sections that are possibly ones we should add: > > CMA > DMA pool > statistics (e.g. vmpressure.c, vmstat.c) > > But these could go to misc for the time being also. > > Of these 3 possibly statistics is the one that makes the best case I think. > > > > > > +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. > > > > > +F: mm/maccess.c > > > +F: mm/mapping_dirty_helpers.c > > > F: mm/memory.c > >+F: mm/memremap.c > > > > memory hotplug related. Well, one could argue that it's just a memory > > hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be > > worth a separate section ... > > Hm not sure? Again maybe best for misc for now until we decide :) It seems relatively small, but if we decide it needs it's own section feel free to put my name down. > > > > > +F: mm/mmu_notifier.c > > > +F: mm/mmzone.c > > > +F: mm/oom_kill.c > > > > This contains quite some meat. I wonder if a OOM section would be > > appropriate (Michal, I'm looking at you :) ) > > As Shakeel points out that's already done (see [0]). > > [0]: https://lore.kernel.org/linux-mm/20250617085819.355838-1-mhocko@kernel.org/ > > > > > > > -- > > Cheers, > > > > David / dhildenb > > >
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 <lorenzo.stoakes@oracle.com> > > --- > > 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. Maybe rather than add files to MM CORE we should move mm/ there and add the MM MISC section for files we explicitly want to exclude from MM CORE? > > @@ -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 ;) The same people that maintain MM CORE? ;-) > > +F: mm/folio-compat.c > > +F: mm/highmem.c > > F: mm/init-mm.c > > +F: mm/internal.h > > +F: mm/interval_tree.c Looks like VMA to me. > > +F: mm/io-mapping.c This is an interesting one. There are no in tree users of the only function it contains. > > +F: mm/ioremap.c > > +F: mm/list_lru.c > > Smells like reclaim/memcg. > > > +F: mm/maccess.c > > +F: mm/mapping_dirty_helpers.c > > F: mm/memory.c > > +F: mm/memremap.c > > memory hotplug related. Well, one could argue that it's just a memory > hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be > worth a separate section ... > > > +F: mm/mmu_notifier.c > > +F: mm/mmzone.c > > +F: mm/oom_kill.c > > This contains quite some meat. I wonder if a OOM section would be > appropriate (Michal, I'm looking at you :) ) > > -- > Cheers, > > David / dhildenb -- Sincerely yours, Mike.
On Tue, Jun 17, 2025 at 06:53:53AM +0300, Mike Rapoport wrote: > > > > +F: mm/io-mapping.c > > This is an interesting one. There are no in tree users of the only function > it contains. Hi Christoph, Was going through and making sure mm files have places in MAINTAINERS and came across this - I see you added this, but it doesn't appear to be being used anywhere. Should it be removed or if not wonder where it ought to go? We're contemplating an 'MM MISC' section where it could live potentially. Cheers, Lorenzo
On 7/22/25 15:53, Lorenzo Stoakes wrote:
> On Tue, Jun 17, 2025 at 06:53:53AM +0300, Mike Rapoport wrote:
>>
>> > > +F: mm/io-mapping.c
>>
>> This is an interesting one. There are no in tree users of the only function
>> it contains.
>
> Hi Christoph,
>
> Was going through and making sure mm files have places in MAINTAINERS and
> came across this - I see you added this, but it doesn't appear to be being
> used anywhere. Should it be removed or if not wonder where it ought to go?
It seems it only gained its only user in b739f125e4eb ("i915: use
io_mapping_map_user") but reverted a month later by 0e4fe0c9f2f9 ("Revert
"i915: use io_mapping_map_user"") all that in 2021.
Ideally i915 would be converted again with the revert reasons investigated
properly this time. Otherwise we should remove the thing.
> We're contemplating an 'MM MISC' section where it could live potentially.
>
> Cheers, Lorenzo
On Tue, Jul 22, 2025 at 04:22:59PM +0200, Vlastimil Babka wrote:
> It seems it only gained its only user in b739f125e4eb ("i915: use
> io_mapping_map_user") but reverted a month later by 0e4fe0c9f2f9 ("Revert
> "i915: use io_mapping_map_user"") all that in 2021.
>
> Ideally i915 would be converted again with the revert reasons investigated
> properly this time. Otherwise we should remove the thing.
Yeah, someone needs to sort the i915 mess, and it's sad they just
reverted things instead of trying to understand it.
But until that happens the code is dead and should be removed.
On 17.06.25 05:53, Mike Rapoport 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 <lorenzo.stoakes@oracle.com> >>> --- >>> 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. > > Maybe rather than add files to MM CORE we should move mm/ there and add the > MM MISC section for files we explicitly want to exclude from MM CORE? Also an option, yes, > >>> @@ -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 ;) > > The same people that maintain MM CORE? ;-) Heh :P > >>> +F: mm/folio-compat.c >>> +F: mm/highmem.c >>> F: mm/init-mm.c >>> +F: mm/internal.h >>> +F: mm/interval_tree.c > > Looks like VMA to me. It's more about anon_vma I guess, so rmap ... maybe. -- Cheers, David / dhildenb
On Tue, Jun 17, 2025 at 09:59:01AM +0200, David Hildenbrand wrote: > On 17.06.25 05:53, Mike Rapoport 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 <lorenzo.stoakes@oracle.com> > > > > --- > > > > 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. > > > > Maybe rather than add files to MM CORE we should move mm/ there and add the > > MM MISC section for files we explicitly want to exclude from MM CORE? > > Also an option, yes, These suggestions seem to be roughly the same no? :) Maybe the MM section itself should just contain mm/ and we move everything else + stragglers to misc? Now who, whose's first name begins with 'D' and surname begins with 'H' should we put as M there... :P well... > > > > > @@ -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 ;) > > > > The same people that maintain MM CORE? ;-) > > Heh :P ...hmm yes easier to just copy/paste these good idea ;) > > > > > +F: mm/folio-compat.c > > > > +F: mm/highmem.c > > > > F: mm/init-mm.c > > > > +F: mm/internal.h > > > > +F: mm/interval_tree.c > > > > Looks like VMA to me. > > It's more about anon_vma I guess, so rmap ... maybe. Ack. > > -- > Cheers, > > David / dhildenb >
On 17.06.25 17:04, Lorenzo Stoakes wrote: > On Tue, Jun 17, 2025 at 09:59:01AM +0200, David Hildenbrand wrote: >> On 17.06.25 05:53, Mike Rapoport 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 <lorenzo.stoakes@oracle.com> >>>>> --- >>>>> 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. >>> >>> Maybe rather than add files to MM CORE we should move mm/ there and add the >>> MM MISC section for files we explicitly want to exclude from MM CORE? >> >> Also an option, yes, > > These suggestions seem to be roughly the same no? :) > > Maybe the MM section itself should just contain mm/ and we move everything else > + stragglers to misc? > > Now who, whose's first name begins with 'D' and surname begins with 'H' should > we put as M there... :P well... Most of these files are fairly small with little activity, so I don't particularly care. Happy once the real big things in there (e.g., OOM) have a dedicate section. -- Cheers, David / dhildenb
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 <lorenzo.stoakes@oracle.com> > > --- > > 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) > > > +F: mm/maccess.c > > +F: mm/mapping_dirty_helpers.c > > F: mm/memory.c> +F: mm/memremap.c > > memory hotplug related. Well, one could argue that it's just a memory > hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be > worth a separate section ... > > > +F: mm/mmu_notifier.c > > +F: mm/mmzone.c > > +F: mm/oom_kill.c > > This contains quite some meat. I wonder if a OOM section would be > appropriate (Michal, I'm looking at you :) ) > I think Michal already has a patch on OOM section which I expect he will send out soon.
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 <lorenzo.stoakes@oracle.com> > > > --- > > > 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? > > > > > > +F: mm/maccess.c > > > +F: mm/mapping_dirty_helpers.c > > > F: mm/memory.c> +F: mm/memremap.c > > > > memory hotplug related. Well, one could argue that it's just a memory > > hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be > > worth a separate section ... > > > > > +F: mm/mmu_notifier.c > > > +F: mm/mmzone.c > > > +F: mm/oom_kill.c > > > > This contains quite some meat. I wonder if a OOM section would be > > appropriate (Michal, I'm looking at you :) ) > > > > I think Michal already has a patch on OOM section which I expect he will > send out soon. > Yes saw that and acked that thanks :)
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 <lorenzo.stoakes@oracle.com> > > > > --- > > > > 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.
On Tue, Jun 17, 2025 at 10:51:50AM -0700, Shakeel Butt wrote: > 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 <lorenzo.stoakes@oracle.com> > > > > > --- > > > > > 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. Ahhh you're right! Sorry, not very familiar with this code so going off a fuzzy match as to what uses these functions etc. So it seems then that include/linux/list_lru.h and mm/list_lru.c belong in the shrinker section, ack will move over there when I tackle the rest of this! Cheers! :)
© 2016 - 2025 Red Hat, Inc.