diff mbox series

[v4,7/7] Update maintainer contact for migration multifd zero page checking acceleration.

Message ID 20240301022829.3390548-8-hao.xiang@bytedance.com
State New
Headers show
Series Introduce multifd zero page checking. | expand

Commit Message

Hao Xiang March 1, 2024, 2:28 a.m. UTC
Add myself to maintain multifd zero page checking acceleration function.

Signed-off-by: Hao Xiang <hao.xiang@bytedance.com>
---
 MAINTAINERS | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Peter Xu March 4, 2024, 7:34 a.m. UTC | #1
On Fri, Mar 01, 2024 at 02:28:29AM +0000, Hao Xiang wrote:
> Add myself to maintain multifd zero page checking acceleration function.
> 
> Signed-off-by: Hao Xiang <hao.xiang@bytedance.com>
> ---
>  MAINTAINERS | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 65dfdc9677..b547918e4d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3414,6 +3414,11 @@ F: tests/migration/
>  F: util/userfaultfd.c
>  X: migration/rdma*
>  
> +Migration multifd zero page checking acceleration
> +M: Hao Xiang <hao.xiang@bytedance.com>
> +S: Maintained
> +F: migration/multifd-zero-page.c
> +

Firstly appreciate a lot for volunteering!

My fault to not have made it clear.  This file alone so far will need to be
closely related to the multifd core, so whoever maintains migration should
look after this.  It's also slightly weird to have a separate entry for a
file that is tens of LOC if it's already covered by another upper entry.

What I worry is about vendor/library specific parts that will be harder to
maintain, and migration maintainers (no matter who does the job in the
future) may not always cover those areas.  So I was expecting we could have
volunteers covering e.g. QAT / DSA / IAA accelerators.  Since all these
accelerators will all be part of Intel's new chips, there's also one way
that we have "Intel accelerators" section to cover vendor specific codes
and then cover all those areas no matter it's zero detect accelerator or HW
compressors.

I'd suggest we discuss this with Intel people to check out a solid plan
later when we start to merge HW/LIB specific codes.  For now I suggest we
can drop this patch and stick with the feature implementation, to see
whether it can catch the train for 9.0.  IMHO this is a good feature even
without HW accelerators (and I think it's close to ready), so I hope it can
still make it.

Thanks,
Hao Xiang March 9, 2024, 8:13 a.m. UTC | #2
> 
> On Sun, Mar 3, 2024 at 11:34 PM Peter Xu <peterx@redhat.com> wrote:
> 
> > 
> > On Fri, Mar 01, 2024 at 02:28:29AM +0000, Hao Xiang wrote:
> > 
> >  Add myself to maintain multifd zero page checking acceleration function.
> > 
> >  Signed-off-by: Hao Xiang <hao.xiang@bytedance.com>
> > 
> >  ---
> > 
> >  MAINTAINERS | 5 +++++
> > 
> >  1 file changed, 5 insertions(+)
> > 
> >  diff --git a/MAINTAINERS b/MAINTAINERS
> > 
> >  index 65dfdc9677..b547918e4d 100644
> > 
> >  --- a/MAINTAINERS
> > 
> >  +++ b/MAINTAINERS
> > 
> >  @@ -3414,6 +3414,11 @@ F: tests/migration/
> > 
> >  F: util/userfaultfd.c
> > 
> >  X: migration/rdma*
> > 
> >  +Migration multifd zero page checking acceleration
> > 
> >  +M: Hao Xiang <hao.xiang@bytedance.com>
> > 
> >  +S: Maintained
> > 
> >  +F: migration/multifd-zero-page.c
> > 
> >  +
> > 
> >  Firstly appreciate a lot for volunteering!
> > 
> >  My fault to not have made it clear. This file alone so far will need to be
> > 
> >  closely related to the multifd core, so whoever maintains migration should
> > 
> >  look after this. It's also slightly weird to have a separate entry for a
> > 
> >  file that is tens of LOC if it's already covered by another upper entry.
> > 
> >  What I worry is about vendor/library specific parts that will be harder to
> > 
> >  maintain, and migration maintainers (no matter who does the job in the
> > 
> >  future) may not always cover those areas. So I was expecting we could have
> > 
> >  volunteers covering e.g. QAT / DSA / IAA accelerators. Since all these
> > 
> >  accelerators will all be part of Intel's new chips, there's also one way
> > 
> >  that we have "Intel accelerators" section to cover vendor specific codes
> > 
> >  and then cover all those areas no matter it's zero detect accelerator or HW
> > 
> >  compressors.
> > 
> >  I'd suggest we discuss this with Intel people to check out a solid plan
> > 
> >  later when we start to merge HW/LIB specific codes. For now I suggest we
> > 
> >  can drop this patch and stick with the feature implementation, to see
> > 
> >  whether it can catch the train for 9.0. IMHO this is a good feature even
> > 
> >  without HW accelerators (and I think it's close to ready), so I hope it can
> > 
> >  still make it.
> > 
> >  Thanks,

No worries. I misunderstood you. We can talk about maintenance later on when we have the accelerator changes ready.

> > 
> >  --
> > 
> >  Peter Xu
> >
>
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index 65dfdc9677..b547918e4d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3414,6 +3414,11 @@  F: tests/migration/
 F: util/userfaultfd.c
 X: migration/rdma*
 
+Migration multifd zero page checking acceleration
+M: Hao Xiang <hao.xiang@bytedance.com>
+S: Maintained
+F: migration/multifd-zero-page.c
+
 RDMA Migration
 R: Li Zhijian <lizhijian@fujitsu.com>
 R: Peter Xu <peterx@redhat.com>