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

[hao.xiang@linux.dev]

> 
> 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
> >
>