| Message ID | 20240301022829.3390548-8-hao.xiang@bytedance.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Introduce multifd zero page checking. | expand |
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,
> > 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 --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>
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(+)