As part of the ongoing efforts to sub-divide memory management
maintainership and reviewership, establish a section for GUP (Get User
Pages) support and add appropriate maintainers and reviewers.

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
 MAINTAINERS | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d274e6802ba5..9c769f7d135b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15540,6 +15540,18 @@ S:	Maintained
 F:	include/linux/execmem.h
 F:	mm/execmem.c
 
+MEMORY MANAGEMENT - GUP (GET USER PAGES)
+M:	Andrew Morton <akpm@linux-foundation.org>
+M:	David Hildenbrand <david@redhat.com>
+R:	Jason Gunthorpe <jgg@nvidia.com>
+R:	John Hubbard <jhubbard@nvidia.com>
+R:	Peter Xu <peterx@redhat.com>
+L:	linux-mm@kvack.org
+S:	Maintained
+W:	http://www.linux-mm.org
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
+F:	mm/gup.c
+
 MEMORY MANAGEMENT - NUMA MEMBLOCKS AND NUMA EMULATION
 M:	Andrew Morton <akpm@linux-foundation.org>
 M:	Mike Rapoport <rppt@kernel.org>
-- 
2.49.0

On Tue,  6 May 2025 18:36:01 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:

> As part of the ongoing efforts to sub-divide memory management
> maintainership and reviewership, establish a section for GUP (Get User
> Pages) support and add appropriate maintainers and reviewers.
> 

Thanks, I was wondering about that.

(looks at vmscan.c)

On 07.05.25 01:21, Andrew Morton wrote:
> On Tue,  6 May 2025 18:36:01 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> 
>> As part of the ongoing efforts to sub-divide memory management
>> maintainership and reviewership, establish a section for GUP (Get User
>> Pages) support and add appropriate maintainers and reviewers.
>>
> 
> Thanks, I was wondering about that.

Thanks Lorenzo for driving this!

Acked-by: David Hildenbrand <david@redhat.com>

> 
> (looks at vmscan.c)

Current maintainers (mm/unstable) on 20 biggest files in mm, Andrew is 
implicit:

  $ find mm -name "*.c" -type f | xargs wc -l | sort -n -r | head -20
  198195 total
    7937 mm/hugetlb.c		# Muchun
    7881 mm/slub.c		# Christoph/David/Vlastimil
    7745 mm/vmscan.c		#
    7424 mm/page_alloc.c		#
    7166 mm/memory.c		# David
    5962 mm/shmem.c		# Hugh
    5553 mm/memcontrol.c		# Johannes/Roman/Shakeel
    5245 mm/vmalloc.c		#
    4703 mm/huge_memory.c	# David
    4538 mm/filemap.c		# Willy
    3964 mm/swapfile.c		#
    3871 mm/ksm.c		#
    3720 mm/gup.c		# David
    3675 mm/mempolicy.c		#
    3371 mm/percpu.c		# Dennis/Tejun/Christoph
    3370 mm/compaction.c		#
    3197 mm/page-writeback.c	# Willy
    3097 mm/vma.c		# Liam/Lorenzo
    2988 mm/rmap.c		# David/Lorenzo

I've been messing with KSM for a long time, so I could easily jump in as 
maintainer for that. Probably we want page migration (incl. mempolicy?) 
as a separate entry. I've been messing with that as well (and will be 
messing more), so I could jump in for that as well.

For page allocator stuff (incl. compaction) we at least have plenty of 
reviewers now. For vmalloc we at least have Uladzislau as single reviewer.

vmscan.c and vmalloc.c really need some love.

-- 
Cheers,

David / dhildenb

On Wed, May 07, 2025 at 10:05:58AM +0200, David Hildenbrand wrote:
> On 07.05.25 01:21, Andrew Morton wrote:
> > On Tue,  6 May 2025 18:36:01 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> > 
> > > As part of the ongoing efforts to sub-divide memory management
> > > maintainership and reviewership, establish a section for GUP (Get User
> > > Pages) support and add appropriate maintainers and reviewers.
> > > 
> > 
> > Thanks, I was wondering about that.
> 
> Thanks Lorenzo for driving this!
> 
> Acked-by: David Hildenbrand <david@redhat.com>
> 
> > 
> > (looks at vmscan.c)
> 
> Current maintainers (mm/unstable) on 20 biggest files in mm, Andrew is
> implicit:
> 
>  $ find mm -name "*.c" -type f | xargs wc -l | sort -n -r | head -20
>  198195 total
>    7937 mm/hugetlb.c		# Muchun
>    7881 mm/slub.c		# Christoph/David/Vlastimil
>    7745 mm/vmscan.c		#
>    7424 mm/page_alloc.c		#
>    7166 mm/memory.c		# David
>    5962 mm/shmem.c		# Hugh
>    5553 mm/memcontrol.c		# Johannes/Roman/Shakeel
>    5245 mm/vmalloc.c		#
>    4703 mm/huge_memory.c	# David
>    4538 mm/filemap.c		# Willy
>    3964 mm/swapfile.c		#
>    3871 mm/ksm.c		#
>    3720 mm/gup.c		# David
>    3675 mm/mempolicy.c		#
>    3371 mm/percpu.c		# Dennis/Tejun/Christoph
>    3370 mm/compaction.c		#
>    3197 mm/page-writeback.c	# Willy
>    3097 mm/vma.c		# Liam/Lorenzo
>    2988 mm/rmap.c		# David/Lorenzo
> 
> I've been messing with KSM for a long time, so I could easily jump in as
> maintainer for that. Probably we want page migration (incl. mempolicy?) as a
> separate entry. I've been messing with that as well (and will be messing
> more), so I could jump in for that as well.
> 
> For page allocator stuff (incl. compaction) we at least have plenty of
> reviewers now. For vmalloc we at least have Uladzislau as single reviewer.
> 
> vmscan.c and vmalloc.c really need some love.
> 
As for "vmalloc.c" i can jump in as an extra maintainer aside with
Andrew if no objections.

--
Uladzislau Rezki

+cc Vlastimil for page_alloc.c stuff.

On Wed, May 07, 2025 at 11:02:00AM +0200, Uladzislau Rezki wrote:
> On Wed, May 07, 2025 at 10:05:58AM +0200, David Hildenbrand wrote:
> > On 07.05.25 01:21, Andrew Morton wrote:
> > > On Tue,  6 May 2025 18:36:01 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> > >
> > > > As part of the ongoing efforts to sub-divide memory management
> > > > maintainership and reviewership, establish a section for GUP (Get User
> > > > Pages) support and add appropriate maintainers and reviewers.
> > > >
> > >
> > > Thanks, I was wondering about that.
> >
> > Thanks Lorenzo for driving this!
> >
> > Acked-by: David Hildenbrand <david@redhat.com>

Thanks David!

Am trying to strike while the iron is hot post-lsf and discuss with people and
set things in motion :)

> >
> > >
> > > (looks at vmscan.c)
> >
> > Current maintainers (mm/unstable) on 20 biggest files in mm, Andrew is
> > implicit:
> >
> >  $ find mm -name "*.c" -type f | xargs wc -l | sort -n -r | head -20
> >  198195 total
> >    7937 mm/hugetlb.c		# Muchun
> >    7881 mm/slub.c		# Christoph/David/Vlastimil
> >    7745 mm/vmscan.c		#

This is, as Andrew rightly points out, a key one, I will have a look around
the git history and put something together here. I'm not sure if we will
get an M here, but at least can populate some reviewers.

> >    7424 mm/page_alloc.c		#

Yeah Vlastimil put effort into sorting out reviewers here (thanks
Vlastimil!) but nobody's stepped up for an M yet :)

> >    7166 mm/memory.c		# David
> >    5962 mm/shmem.c		# Hugh
> >    5553 mm/memcontrol.c		# Johannes/Roman/Shakeel
> >    5245 mm/vmalloc.c		#

As discussed below 100% Ulad is very clearly the right guy for M (and who
has graciously offered his services as such) :>)

Ulad - do you want to send a patch upgrading yourself there? cc me and
David, I will happily ack of course, and I suspect David as well!

> >    4703 mm/huge_memory.c	# David
> >    4538 mm/filemap.c		# Willy
> >    3964 mm/swapfile.c		#

The various discussions at LSF lend themselves to suggesting people here,
can take a look at this also.

> >    3871 mm/ksm.c		#

As per discussion below, thanks for suggesting yourself David, I hope this
is a case of 'well de facto I am maintaining this' rather than taking
anything new on, as I worry about how much your workload involves :P

I will sniff around the git history too and put something together.

> >    3720 mm/gup.c		# David
> >    3675 mm/mempolicy.c		#

Ack below, and will take a look here also.

> >    3371 mm/percpu.c		# Dennis/Tejun/Christoph
> >    3370 mm/compaction.c		#

As you say lots of R's which is good.

As per below would you want M for this?

I will take a look also.

> >    3197 mm/page-writeback.c	# Willy
> >    3097 mm/vma.c		# Liam/Lorenzo
> >    2988 mm/rmap.c		# David/Lorenzo

> >
> > I've been messing with KSM for a long time, so I could easily jump in as
> > maintainer for that. Probably we want page migration (incl. mempolicy?) as a
> > separate entry. I've been messing with that as well (and will be messing
> > more), so I could jump in for that as well.
> >
> > For page allocator stuff (incl. compaction) we at least have plenty of
> > reviewers now. For vmalloc we at least have Uladzislau as single reviewer.
> >
> > vmscan.c and vmalloc.c really need some love.
> >
> As for "vmalloc.c" i can jump in as an extra maintainer aside with
> Andrew if no objections.

Entirely the opposite of an objection, I'd be aghast if you weren't a
maintainer there, thank you for your excellent work in vmalloc, you're a
top chap and we're very lucky to have you working on this!

>
> --
> Uladzislau Rezki

Cheers, Lorenzo

+cc Johannes

On Wed, May 07, 2025 at 10:23:34AM +0100, Lorenzo Stoakes wrote:
>
> > > > (looks at vmscan.c)
> > >
> > > Current maintainers (mm/unstable) on 20 biggest files in mm, Andrew is
> > > implicit:
> > >
> > >  $ find mm -name "*.c" -type f | xargs wc -l | sort -n -r | head -20
> > >  198195 total
> > >    7937 mm/hugetlb.c		# Muchun
> > >    7881 mm/slub.c		# Christoph/David/Vlastimil
> > >    7745 mm/vmscan.c		#
> 
> This is, as Andrew rightly points out, a key one, I will have a look around
> the git history and put something together here. I'm not sure if we will
> get an M here, but at least can populate some reviewers.

I remember Johannes doing a lot of work in vmscan, let's volunteer him :)
 
> Cheers, Lorenzo
> 

-- 
Sincerely yours,
Mike.

>>>> (looks at vmscan.c)
>>>
>>> Current maintainers (mm/unstable) on 20 biggest files in mm, Andrew is
>>> implicit:
>>>
>>>   $ find mm -name "*.c" -type f | xargs wc -l | sort -n -r | head -20
>>>   198195 total
>>>     7937 mm/hugetlb.c		# Muchun
>>>     7881 mm/slub.c		# Christoph/David/Vlastimil
>>>     7745 mm/vmscan.c		#
> 
> This is, as Andrew rightly points out, a key one, I will have a look around
> the git history and put something together here. I'm not sure if we will
> get an M here, but at least can populate some reviewers.

Yes. I would assume that at least MGLRU people are reviewing this ... 
and probably memcg folks :)

[...]

> 
>>>     4703 mm/huge_memory.c	# David
>>>     4538 mm/filemap.c		# Willy
>>>     3964 mm/swapfile.c		#
> 
> The various discussions at LSF lend themselves to suggesting people here,
> can take a look at this also.

Yes, we should be able to come up with some R.

> 
>>>     3871 mm/ksm.c		#
> 
> As per discussion below, thanks for suggesting yourself David, I hope this
> is a case of 'well de facto I am maintaining this'

Yeah, it's exactly that I'm afraid :)

> rather than taking
> anything new on, as I worry about how much your workload involves :P
 > > I will sniff around the git history too and put something together.
> 
>>>     3720 mm/gup.c		# David
>>>     3675 mm/mempolicy.c		#
> 
> Ack below, and will take a look here also.
> 
>>>     3371 mm/percpu.c		# Dennis/Tejun/Christoph
>>>     3370 mm/compaction.c		#
> 
> As you say lots of R's which is good.
> 
> As per below would you want M for this?

Probably we'd want a migration section with sth. like

* mm/migrate.c
* mm/migrate_device.c
* include/linux/migrate.h

And maybe we also want also the following files in there (a separate 
section might not make sense)

* include/linux/mempolicy.h
* mm/mempolicy.c


MEMORY POLICY AND MIGRATION ? I think I should have the capacity to be M 
for that.


mm/compaction.c is a bit in-between the page allocator and migration 
right now, but I think long-term stuff should simply me moved to the 
proper files and compaction.c should be a consumer of migration 
functionality. And likely compaction.c should stay in the "PAGE 
ALLOCATOR" section.

M for "PAGE ALLOCATOR", hmmm ..., I was hoping that Vlastimil might have 
capacity for that? :)



Not 100% sure what to do with

* include/linux/page_isolation.h
* mm/page_isolation.c

(I hate the word "page isolation")

They are mostly about page migration (either for alloc_contig... or 
memory hotunplug). Likely they should either go to the MIGRATION section 
or to the PAGE ALLOCATOR? Maybe MIGRATION makes more sense. Thoughts?

-- 
Cheers,

David / dhildenb

On Thu, May 08, 2025 at 10:53:22AM +0200, David Hildenbrand wrote:
> > > > > (looks at vmscan.c)
> > > >
> > > > Current maintainers (mm/unstable) on 20 biggest files in mm, Andrew is
> > > > implicit:
> > > >
> > > >   $ find mm -name "*.c" -type f | xargs wc -l | sort -n -r | head -20
> > > >   198195 total
> > > >     7937 mm/hugetlb.c		# Muchun
> > > >     7881 mm/slub.c		# Christoph/David/Vlastimil
> > > >     7745 mm/vmscan.c		#
> >
> > This is, as Andrew rightly points out, a key one, I will have a look around
> > the git history and put something together here. I'm not sure if we will
> > get an M here, but at least can populate some reviewers.
>
> Yes. I would assume that at least MGLRU people are reviewing this ... and
> probably memcg folks :)

Ack indeed, will try to figure out who best to include.

Will either RFC or send off-list message to coordinate.

>
> [...]
>
> >
> > > >     4703 mm/huge_memory.c	# David
> > > >     4538 mm/filemap.c		# Willy
> > > >     3964 mm/swapfile.c		#
> >
> > The various discussions at LSF lend themselves to suggesting people here,
> > can take a look at this also.
>
> Yes, we should be able to come up with some R.
>
> >
> > > >     3871 mm/ksm.c		#
> >
> > As per discussion below, thanks for suggesting yourself David, I hope this
> > is a case of 'well de facto I am maintaining this'
>
> Yeah, it's exactly that I'm afraid :)

:)) I mean the same in my case also of course. Though far, far fewer
instances for me...

>
> > rather than taking
> > anything new on, as I worry about how much your workload involves :P
> > > I will sniff around the git history too and put something together.
> >
> > > >     3720 mm/gup.c		# David
> > > >     3675 mm/mempolicy.c		#
> >
> > Ack below, and will take a look here also.
> >
> > > >     3371 mm/percpu.c		# Dennis/Tejun/Christoph
> > > >     3370 mm/compaction.c		#
> >
> > As you say lots of R's which is good.
> >
> > As per below would you want M for this?
>
> Probably we'd want a migration section with sth. like
>
> * mm/migrate.c
> * mm/migrate_device.c
> * include/linux/migrate.h
>
> And maybe we also want also the following files in there (a separate section
> might not make sense)
>
> * include/linux/mempolicy.h
> * mm/mempolicy.c
>
>
> MEMORY POLICY AND MIGRATION ? I think I should have the capacity to be M for
> that.

Ack makes sense, will sort something out.

>
>
> mm/compaction.c is a bit in-between the page allocator and migration right
> now, but I think long-term stuff should simply me moved to the proper files
> and compaction.c should be a consumer of migration functionality. And likely
> compaction.c should stay in the "PAGE ALLOCATOR" section.

Ack!

>
> M for "PAGE ALLOCATOR", hmmm ..., I was hoping that Vlastimil might have
> capacity for that? :)

Vlastimil? ;)

I'd certainly support this.

>
>
>
> Not 100% sure what to do with
>
> * include/linux/page_isolation.h
> * mm/page_isolation.c
>
> (I hate the word "page isolation")
>
> They are mostly about page migration (either for alloc_contig... or memory
> hotunplug). Likely they should either go to the MIGRATION section or to the
> PAGE ALLOCATOR? Maybe MIGRATION makes more sense. Thoughts?

I mean it explicitly relates to migrate type and migration so seems to me
it ought to be in migration.

Though migrate type + the machinary around it is a product of the physical
page allocator (I even cover it in the 'physical memory' section of the
book).

I wonder if our soon-to-be page allocator maintainer Vlastimil has
thoughts? ;)

I'd vote for migration though to be honest.

>
> --
> Cheers,
>
> David / dhildenb
>

On 5/8/25 14:23, Lorenzo Stoakes wrote:
>>
>> M for "PAGE ALLOCATOR", hmmm ..., I was hoping that Vlastimil might have
>> capacity for that? :)
> 
> Vlastimil? ;)
> 
> I'd certainly support this.

OK, can do, thanks.

>>
>>
>>
>> Not 100% sure what to do with
>>
>> * include/linux/page_isolation.h
>> * mm/page_isolation.c
>>
>> (I hate the word "page isolation")
>>
>> They are mostly about page migration (either for alloc_contig... or memory
>> hotunplug). Likely they should either go to the MIGRATION section or to the
>> PAGE ALLOCATOR? Maybe MIGRATION makes more sense. Thoughts?
> 
> I mean it explicitly relates to migrate type and migration so seems to me
> it ought to be in migration.
> 
> Though migrate type + the machinary around it is a product of the physical
> page allocator (I even cover it in the 'physical memory' section of the
> book).
> 
> I wonder if our soon-to-be page allocator maintainer Vlastimil has
> thoughts? ;)
> 
> I'd vote for migration though to be honest.

I checked the code briefly and although migratetypes are related to
migration, it seems rather page allocator code to me.

In fact if I didn't miss these files, I would have included them when
proposing the PAGE ALLOCATOR section.
Zi Yan has a series on that topic now and is one of the R: in PAGE
ALLOCATOR. What do you think?

>>
>> --
>> Cheers,
>>
>> David / dhildenb
>>

On 12 May 2025, at 3:38, Vlastimil Babka wrote:

> On 5/8/25 14:23, Lorenzo Stoakes wrote:
>>>
>>> M for "PAGE ALLOCATOR", hmmm ..., I was hoping that Vlastimil might have
>>> capacity for that? :)
>>
>> Vlastimil? ;)
>>
>> I'd certainly support this.
>
> OK, can do, thanks.
>
>>>
>>>
>>>
>>> Not 100% sure what to do with
>>>
>>> * include/linux/page_isolation.h
>>> * mm/page_isolation.c
>>>
>>> (I hate the word "page isolation")
>>>
>>> They are mostly about page migration (either for alloc_contig... or memory
>>> hotunplug). Likely they should either go to the MIGRATION section or to the
>>> PAGE ALLOCATOR? Maybe MIGRATION makes more sense. Thoughts?
>>
>> I mean it explicitly relates to migrate type and migration so seems to me
>> it ought to be in migration.
>>
>> Though migrate type + the machinary around it is a product of the physical
>> page allocator (I even cover it in the 'physical memory' section of the
>> book).
>>
>> I wonder if our soon-to-be page allocator maintainer Vlastimil has
>> thoughts? ;)
>>
>> I'd vote for migration though to be honest.
>
> I checked the code briefly and although migratetypes are related to
> migration, it seems rather page allocator code to me.
>
> In fact if I didn't miss these files, I would have included them when
> proposing the PAGE ALLOCATOR section.
> Zi Yan has a series on that topic now and is one of the R: in PAGE
> ALLOCATOR. What do you think?

I agree with Vlastimil that these two files belong to PAGE ALLOCATOR
section. Page isolation (actually should be pageblock isolation) is
doing work on pageblock migratetype, which IMHO is an important part
of anti-fragmentation mechanism for page allocation.

--
Best Regards,
Yan, Zi

On Mon, May 12, 2025 at 08:54:53AM -0400, Zi Yan wrote:
> On 12 May 2025, at 3:38, Vlastimil Babka wrote:
>
> > On 5/8/25 14:23, Lorenzo Stoakes wrote:
> >>>
> >>> M for "PAGE ALLOCATOR", hmmm ..., I was hoping that Vlastimil might have
> >>> capacity for that? :)
> >>
> >> Vlastimil? ;)
> >>
> >> I'd certainly support this.
> >
> > OK, can do, thanks.
> >
> >>>
> >>>
> >>>
> >>> Not 100% sure what to do with
> >>>
> >>> * include/linux/page_isolation.h
> >>> * mm/page_isolation.c
> >>>
> >>> (I hate the word "page isolation")
> >>>
> >>> They are mostly about page migration (either for alloc_contig... or memory
> >>> hotunplug). Likely they should either go to the MIGRATION section or to the
> >>> PAGE ALLOCATOR? Maybe MIGRATION makes more sense. Thoughts?
> >>
> >> I mean it explicitly relates to migrate type and migration so seems to me
> >> it ought to be in migration.
> >>
> >> Though migrate type + the machinary around it is a product of the physical
> >> page allocator (I even cover it in the 'physical memory' section of the
> >> book).
> >>
> >> I wonder if our soon-to-be page allocator maintainer Vlastimil has
> >> thoughts? ;)
> >>
> >> I'd vote for migration though to be honest.
> >
> > I checked the code briefly and although migratetypes are related to
> > migration, it seems rather page allocator code to me.
> >
> > In fact if I didn't miss these files, I would have included them when
> > proposing the PAGE ALLOCATOR section.
> > Zi Yan has a series on that topic now and is one of the R: in PAGE
> > ALLOCATOR. What do you think?
>
> I agree with Vlastimil that these two files belong to PAGE ALLOCATOR
> section. Page isolation (actually should be pageblock isolation) is
> doing work on pageblock migratetype, which IMHO is an important part
> of anti-fragmentation mechanism for page allocation.

Ack, will send a patch! :)

Thanks!

>
> --
> Best Regards,
> Yan, Zi

On 12.05.25 14:54, Zi Yan wrote:
> On 12 May 2025, at 3:38, Vlastimil Babka wrote:
> 
>> On 5/8/25 14:23, Lorenzo Stoakes wrote:
>>>>
>>>> M for "PAGE ALLOCATOR", hmmm ..., I was hoping that Vlastimil might have
>>>> capacity for that? :)
>>>
>>> Vlastimil? ;)
>>>
>>> I'd certainly support this.
>>
>> OK, can do, thanks.
>>
>>>>
>>>>
>>>>
>>>> Not 100% sure what to do with
>>>>
>>>> * include/linux/page_isolation.h
>>>> * mm/page_isolation.c
>>>>
>>>> (I hate the word "page isolation")
>>>>
>>>> They are mostly about page migration (either for alloc_contig... or memory
>>>> hotunplug). Likely they should either go to the MIGRATION section or to the
>>>> PAGE ALLOCATOR? Maybe MIGRATION makes more sense. Thoughts?
>>>
>>> I mean it explicitly relates to migrate type and migration so seems to me
>>> it ought to be in migration.
>>>
>>> Though migrate type + the machinary around it is a product of the physical
>>> page allocator (I even cover it in the 'physical memory' section of the
>>> book).
>>>
>>> I wonder if our soon-to-be page allocator maintainer Vlastimil has
>>> thoughts? ;)
>>>
>>> I'd vote for migration though to be honest.
>>
>> I checked the code briefly and although migratetypes are related to
>> migration, it seems rather page allocator code to me.
>>
>> In fact if I didn't miss these files, I would have included them when
>> proposing the PAGE ALLOCATOR section.
>> Zi Yan has a series on that topic now and is one of the R: in PAGE
>> ALLOCATOR. What do you think?
> 
> I agree with Vlastimil that these two files belong to PAGE ALLOCATOR
> section. Page isolation (actually should be pageblock isolation) is
> doing work on pageblock migratetype, which IMHO is an important part
> of anti-fragmentation mechanism for page allocation.

IIRC, it's a bit confusing, because pageblock isolation as in 
mm/page_isolation.c does not have a lot to do with anti-fragmentation in 
reality.

All of these functions should primarily be used for memory offlining + 
alloc_contig. (where we try page migration afterwards)

Anyhow, I am fine as long as these files live somewhere related :)

-- 
Cheers,

David / dhildenb

On Mon, May 12, 2025 at 03:01:30PM +0200, David Hildenbrand wrote:
> On 12.05.25 14:54, Zi Yan wrote:
> > On 12 May 2025, at 3:38, Vlastimil Babka wrote:
> >
> > > On 5/8/25 14:23, Lorenzo Stoakes wrote:
> > > > >
> > > > > M for "PAGE ALLOCATOR", hmmm ..., I was hoping that Vlastimil might have
> > > > > capacity for that? :)
> > > >
> > > > Vlastimil? ;)
> > > >
> > > > I'd certainly support this.
> > >
> > > OK, can do, thanks.
> > >
> > > > >
> > > > >
> > > > >
> > > > > Not 100% sure what to do with
> > > > >
> > > > > * include/linux/page_isolation.h
> > > > > * mm/page_isolation.c
> > > > >
> > > > > (I hate the word "page isolation")
> > > > >
> > > > > They are mostly about page migration (either for alloc_contig... or memory
> > > > > hotunplug). Likely they should either go to the MIGRATION section or to the
> > > > > PAGE ALLOCATOR? Maybe MIGRATION makes more sense. Thoughts?
> > > >
> > > > I mean it explicitly relates to migrate type and migration so seems to me
> > > > it ought to be in migration.
> > > >
> > > > Though migrate type + the machinary around it is a product of the physical
> > > > page allocator (I even cover it in the 'physical memory' section of the
> > > > book).
> > > >
> > > > I wonder if our soon-to-be page allocator maintainer Vlastimil has
> > > > thoughts? ;)
> > > >
> > > > I'd vote for migration though to be honest.
> > >
> > > I checked the code briefly and although migratetypes are related to
> > > migration, it seems rather page allocator code to me.
> > >
> > > In fact if I didn't miss these files, I would have included them when
> > > proposing the PAGE ALLOCATOR section.
> > > Zi Yan has a series on that topic now and is one of the R: in PAGE
> > > ALLOCATOR. What do you think?
> >
> > I agree with Vlastimil that these two files belong to PAGE ALLOCATOR
> > section. Page isolation (actually should be pageblock isolation) is
> > doing work on pageblock migratetype, which IMHO is an important part
> > of anti-fragmentation mechanism for page allocation.
>
> IIRC, it's a bit confusing, because pageblock isolation as in
> mm/page_isolation.c does not have a lot to do with anti-fragmentation in
> reality.
>
> All of these functions should primarily be used for memory offlining +
> alloc_contig. (where we try page migration afterwards)
>
> Anyhow, I am fine as long as these files live somewhere related :)

Yeah, I think key thing is to get them in _somewhere_ vaguely sensible, and
we can figure out fixing up this kind of thing after :) which I think
aligns with what you're saying here!

>
> --
> Cheers,
>
> David / dhildenb
>

I feel we should probably add mm/oom_kill.c, include/linux/mman.h,
mm/internal.h to mm core as a few more key files. What do you think?

We're probably going to be working through a bunch of stragglers for some
time I feel :)

On Thu, May 08, 2025 at 01:23:25PM +0100, Lorenzo Stoakes wrote:
> On Thu, May 08, 2025 at 10:53:22AM +0200, David Hildenbrand wrote:
> > > > > > (looks at vmscan.c)
> > > > >
> > > > > Current maintainers (mm/unstable) on 20 biggest files in mm, Andrew is
> > > > > implicit:
> > > > >
> > > > >   $ find mm -name "*.c" -type f | xargs wc -l | sort -n -r | head -20
> > > > >   198195 total
> > > > >     7937 mm/hugetlb.c		# Muchun
> > > > >     7881 mm/slub.c		# Christoph/David/Vlastimil
> > > > >     7745 mm/vmscan.c		#
> > >
> > > This is, as Andrew rightly points out, a key one, I will have a look around
> > > the git history and put something together here. I'm not sure if we will
> > > get an M here, but at least can populate some reviewers.
> >
> > Yes. I would assume that at least MGLRU people are reviewing this ... and
> > probably memcg folks :)
>
> Ack indeed, will try to figure out who best to include.
>
> Will either RFC or send off-list message to coordinate.
>
> >
> > [...]
> >
> > >
> > > > >     4703 mm/huge_memory.c	# David
> > > > >     4538 mm/filemap.c		# Willy
> > > > >     3964 mm/swapfile.c		#
> > >
> > > The various discussions at LSF lend themselves to suggesting people here,
> > > can take a look at this also.
> >
> > Yes, we should be able to come up with some R.
> >
> > >
> > > > >     3871 mm/ksm.c		#
> > >
> > > As per discussion below, thanks for suggesting yourself David, I hope this
> > > is a case of 'well de facto I am maintaining this'
> >
> > Yeah, it's exactly that I'm afraid :)
>
> :)) I mean the same in my case also of course. Though far, far fewer
> instances for me...
>
> >
> > > rather than taking
> > > anything new on, as I worry about how much your workload involves :P
> > > > I will sniff around the git history too and put something together.
> > >
> > > > >     3720 mm/gup.c		# David
> > > > >     3675 mm/mempolicy.c		#
> > >
> > > Ack below, and will take a look here also.
> > >
> > > > >     3371 mm/percpu.c		# Dennis/Tejun/Christoph
> > > > >     3370 mm/compaction.c		#
> > >
> > > As you say lots of R's which is good.
> > >
> > > As per below would you want M for this?
> >
> > Probably we'd want a migration section with sth. like
> >
> > * mm/migrate.c
> > * mm/migrate_device.c
> > * include/linux/migrate.h
> >
> > And maybe we also want also the following files in there (a separate section
> > might not make sense)
> >
> > * include/linux/mempolicy.h
> > * mm/mempolicy.c
> >
> >
> > MEMORY POLICY AND MIGRATION ? I think I should have the capacity to be M for
> > that.
>
> Ack makes sense, will sort something out.
>
> >
> >
> > mm/compaction.c is a bit in-between the page allocator and migration right
> > now, but I think long-term stuff should simply me moved to the proper files
> > and compaction.c should be a consumer of migration functionality. And likely
> > compaction.c should stay in the "PAGE ALLOCATOR" section.
>
> Ack!
>
> >
> > M for "PAGE ALLOCATOR", hmmm ..., I was hoping that Vlastimil might have
> > capacity for that? :)
>
> Vlastimil? ;)
>
> I'd certainly support this.
>
> >
> >
> >
> > Not 100% sure what to do with
> >
> > * include/linux/page_isolation.h
> > * mm/page_isolation.c
> >
> > (I hate the word "page isolation")
> >
> > They are mostly about page migration (either for alloc_contig... or memory
> > hotunplug). Likely they should either go to the MIGRATION section or to the
> > PAGE ALLOCATOR? Maybe MIGRATION makes more sense. Thoughts?
>
> I mean it explicitly relates to migrate type and migration so seems to me
> it ought to be in migration.
>
> Though migrate type + the machinary around it is a product of the physical
> page allocator (I even cover it in the 'physical memory' section of the
> book).
>
> I wonder if our soon-to-be page allocator maintainer Vlastimil has
> thoughts? ;)
>
> I'd vote for migration though to be honest.
>
> >
> > --
> > Cheers,
> >
> > David / dhildenb
> >

On 08.05.25 18:03, Lorenzo Stoakes wrote:
> I feel we should probably add mm/oom_kill.c, include/linux/mman.h,
> mm/internal.h to mm core as a few more key files. What do you think?

The latte two likely yes.

Hmm, one could argue that oom_kill might be memory reclaim related.

Fortunately, that code is not too complicated ...

> 
> We're probably going to be working through a bunch of stragglers for some
> time I feel :)

Yeah, there are many files ...

-- 
Cheers,

David / dhildenb

On Thu, May 08, 2025 at 07:43:44PM +0200, David Hildenbrand wrote:
> On 08.05.25 18:03, Lorenzo Stoakes wrote:
> > I feel we should probably add mm/oom_kill.c, include/linux/mman.h,
> > mm/internal.h to mm core as a few more key files. What do you think?
>
> The latte two likely yes.
>
> Hmm, one could argue that oom_kill might be memory reclaim related.

I suppose it's an extreme form of reclaim :) or the ultimate state of reclaim,
and of course invoked by reclaim so yeah that makes sense...

I guess when I un-RFC the reclaim patch I can add it in :)

>
> Fortunately, that code is not too complicated ...

Well we're about to have BPF OOM killer right? So this might change soon... it's
also why this came to mind.

>
> >
> > We're probably going to be working through a bunch of stragglers for some
> > time I feel :)
>
> Yeah, there are many files ...

I guess key point is to lay the foundations so we can iterate more over time :)

>
> --
> Cheers,
>
> David / dhildenb
>

On Wed, May 07, 2025 at 10:23:34AM +0100, Lorenzo Stoakes wrote:
> +cc Vlastimil for page_alloc.c stuff.
> 
> On Wed, May 07, 2025 at 11:02:00AM +0200, Uladzislau Rezki wrote:
> > On Wed, May 07, 2025 at 10:05:58AM +0200, David Hildenbrand wrote:
> > > On 07.05.25 01:21, Andrew Morton wrote:
> > > > On Tue,  6 May 2025 18:36:01 +0100 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> > > >
> > > > > As part of the ongoing efforts to sub-divide memory management
> > > > > maintainership and reviewership, establish a section for GUP (Get User
> > > > > Pages) support and add appropriate maintainers and reviewers.
> > > > >
> > > >
> > > > Thanks, I was wondering about that.
> > >
> > > Thanks Lorenzo for driving this!
> > >
> > > Acked-by: David Hildenbrand <david@redhat.com>
> 
> Thanks David!
> 
> Am trying to strike while the iron is hot post-lsf and discuss with people and
> set things in motion :)
> 
> > >
> > > >
> > > > (looks at vmscan.c)
> > >
> > > Current maintainers (mm/unstable) on 20 biggest files in mm, Andrew is
> > > implicit:
> > >
> > >  $ find mm -name "*.c" -type f | xargs wc -l | sort -n -r | head -20
> > >  198195 total
> > >    7937 mm/hugetlb.c		# Muchun
> > >    7881 mm/slub.c		# Christoph/David/Vlastimil
> > >    7745 mm/vmscan.c		#
> 
> This is, as Andrew rightly points out, a key one, I will have a look around
> the git history and put something together here. I'm not sure if we will
> get an M here, but at least can populate some reviewers.
> 
> > >    7424 mm/page_alloc.c		#
> 
> Yeah Vlastimil put effort into sorting out reviewers here (thanks
> Vlastimil!) but nobody's stepped up for an M yet :)
> 
> > >    7166 mm/memory.c		# David
> > >    5962 mm/shmem.c		# Hugh
> > >    5553 mm/memcontrol.c		# Johannes/Roman/Shakeel
> > >    5245 mm/vmalloc.c		#
> 
> As discussed below 100% Ulad is very clearly the right guy for M (and who
> has graciously offered his services as such) :>)
> 
> Ulad - do you want to send a patch upgrading yourself there? cc me and
> David, I will happily ack of course, and I suspect David as well!
> 
I will :)

> > >    4703 mm/huge_memory.c	# David
> > >    4538 mm/filemap.c		# Willy
> > >    3964 mm/swapfile.c		#
> 
> The various discussions at LSF lend themselves to suggesting people here,
> can take a look at this also.
> 
> > >    3871 mm/ksm.c		#
> 
> As per discussion below, thanks for suggesting yourself David, I hope this
> is a case of 'well de facto I am maintaining this' rather than taking
> anything new on, as I worry about how much your workload involves :P
> 
> I will sniff around the git history too and put something together.
> 
> > >    3720 mm/gup.c		# David
> > >    3675 mm/mempolicy.c		#
> 
> Ack below, and will take a look here also.
> 
> > >    3371 mm/percpu.c		# Dennis/Tejun/Christoph
> > >    3370 mm/compaction.c		#
> 
> As you say lots of R's which is good.
> 
> As per below would you want M for this?
> 
> I will take a look also.
> 
> > >    3197 mm/page-writeback.c	# Willy
> > >    3097 mm/vma.c		# Liam/Lorenzo
> > >    2988 mm/rmap.c		# David/Lorenzo
> 
> > >
> > > I've been messing with KSM for a long time, so I could easily jump in as
> > > maintainer for that. Probably we want page migration (incl. mempolicy?) as a
> > > separate entry. I've been messing with that as well (and will be messing
> > > more), so I could jump in for that as well.
> > >
> > > For page allocator stuff (incl. compaction) we at least have plenty of
> > > reviewers now. For vmalloc we at least have Uladzislau as single reviewer.
> > >
> > > vmscan.c and vmalloc.c really need some love.
> > >
> > As for "vmalloc.c" i can jump in as an extra maintainer aside with
> > Andrew if no objections.
> 
> Entirely the opposite of an objection, I'd be aghast if you weren't a
> maintainer there, thank you for your excellent work in vmalloc, you're a
> top chap and we're very lucky to have you working on this!
> 
Thank you i send out that patch today and put into CC you and David!

--
Uladzislau Rezki

On 5/6/25 10:36 AM, Lorenzo Stoakes wrote:
> As part of the ongoing efforts to sub-divide memory management
> maintainership and reviewership, establish a section for GUP (Get User
> Pages) support and add appropriate maintainers and reviewers.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
>   MAINTAINERS | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
> 

Reviewed-by: John Hubbard <jhubbard@nvidia.com>


thanks,
-- 
John Hubbard

> diff --git a/MAINTAINERS b/MAINTAINERS
> index d274e6802ba5..9c769f7d135b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15540,6 +15540,18 @@ S:	Maintained
>   F:	include/linux/execmem.h
>   F:	mm/execmem.c
>   
> +MEMORY MANAGEMENT - GUP (GET USER PAGES)
> +M:	Andrew Morton <akpm@linux-foundation.org>
> +M:	David Hildenbrand <david@redhat.com>
> +R:	Jason Gunthorpe <jgg@nvidia.com>
> +R:	John Hubbard <jhubbard@nvidia.com>
> +R:	Peter Xu <peterx@redhat.com>
> +L:	linux-mm@kvack.org
> +S:	Maintained
> +W:	http://www.linux-mm.org
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> +F:	mm/gup.c
> +
>   MEMORY MANAGEMENT - NUMA MEMBLOCKS AND NUMA EMULATION
>   M:	Andrew Morton <akpm@linux-foundation.org>
>   M:	Mike Rapoport <rppt@kernel.org>