Message ID | 20211126134209.17332-1-david@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | virtio-mem: prepare for granularity smaller than MAX_ORDER - 1 | expand |
On 26 Nov 2021, at 8:42, David Hildenbrand wrote: > The virtio-mem driver currently supports logical hot(un)plug in > MAX_ORDER - 1 granularity (4MiB on x86-64) or bigger. We want to support > pageblock granularity (2MiB on x86-64), to make hot(un)plug even more > flexible, and to improve hotunplug when using ZONE_NORMAL. > > With pageblock granularity, we then have a granularity comparable to > hugepage ballooning. Further, there are ideas to increase MAX_ORDER, so > we really want to decouple it from MAX_ORDER. > > While ZONE_MOVABLE should mostly work already, alloc_contig_range() still > needs work to be able to properly handle pageblock granularity on > ZONE_NORMAL. This support is in the works [1], so let's prepare > virtio-mem for supporting smaller granularity than MAX_ORDER - 1. > > Tested with ZONE_MOVABLE after removing the MAX_ORDER - 1 granularity > limitation in virtio-mem, and using different device block sizes (2MiB, > 4MiB, 8MiB). > > [1] https://lkml.kernel.org/r/20211115193725.737539-1-zi.yan@sent.com The patchset looks good to me. Thanks. Reviewed-by: Zi Yan <ziy@nvidia.com> > Cc: "Michael S. Tsirkin" <mst@redhat.com> > Cc: Jason Wang <jasowang@redhat.com> > Cc: Zi Yan <ziy@nvidia.com> > Cc: Gavin Shan <gshan@redhat.com> > Cc: Hui Zhu <teawater@gmail.com> > Cc: Eric Ren <renzhengeek@gmail.com> > Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> > Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> > Cc: Wei Yang <richard.weiyang@linux.alibaba.com> > Cc: virtualization@lists.linux-foundation.org > Cc: linux-mm@kvack.org > > David Hildenbrand (2): > virtio-mem: prepare page onlining code for granularity smaller than > MAX_ORDER - 1 > virtio-mem: prepare fake page onlining code for granularity smaller > than MAX_ORDER - 1 > > drivers/virtio/virtio_mem.c | 110 ++++++++++++++++++++++++------------ > 1 file changed, 74 insertions(+), 36 deletions(-) > > -- > 2.31.1 -- Best Regards, Yan, Zi
On 29.11.21 17:47, Zi Yan wrote: > On 26 Nov 2021, at 8:42, David Hildenbrand wrote: > >> The virtio-mem driver currently supports logical hot(un)plug in >> MAX_ORDER - 1 granularity (4MiB on x86-64) or bigger. We want to support >> pageblock granularity (2MiB on x86-64), to make hot(un)plug even more >> flexible, and to improve hotunplug when using ZONE_NORMAL. >> >> With pageblock granularity, we then have a granularity comparable to >> hugepage ballooning. Further, there are ideas to increase MAX_ORDER, so >> we really want to decouple it from MAX_ORDER. >> >> While ZONE_MOVABLE should mostly work already, alloc_contig_range() still >> needs work to be able to properly handle pageblock granularity on >> ZONE_NORMAL. This support is in the works [1], so let's prepare >> virtio-mem for supporting smaller granularity than MAX_ORDER - 1. >> >> Tested with ZONE_MOVABLE after removing the MAX_ORDER - 1 granularity >> limitation in virtio-mem, and using different device block sizes (2MiB, >> 4MiB, 8MiB). >> >> [1] https://lkml.kernel.org/r/20211115193725.737539-1-zi.yan@sent.com > > The patchset looks good to me. Thanks. Reviewed-by: Zi Yan <ziy@nvidia.com> Thanks a lot!
On Fri, Nov 26, 2021 at 02:42:07PM +0100, David Hildenbrand wrote: > The virtio-mem driver currently supports logical hot(un)plug in > MAX_ORDER - 1 granularity (4MiB on x86-64) or bigger. We want to support > pageblock granularity (2MiB on x86-64), to make hot(un)plug even more > flexible, and to improve hotunplug when using ZONE_NORMAL. > > With pageblock granularity, we then have a granularity comparable to > hugepage ballooning. Further, there are ideas to increase MAX_ORDER, so > we really want to decouple it from MAX_ORDER. > > While ZONE_MOVABLE should mostly work already, alloc_contig_range() still > needs work to be able to properly handle pageblock granularity on > ZONE_NORMAL. This support is in the works [1], so let's prepare > virtio-mem for supporting smaller granularity than MAX_ORDER - 1. is there value to merging this seprately? or should this just be part of that patchset? > Tested with ZONE_MOVABLE after removing the MAX_ORDER - 1 granularity > limitation in virtio-mem, and using different device block sizes (2MiB, > 4MiB, 8MiB). > > [1] https://lkml.kernel.org/r/20211115193725.737539-1-zi.yan@sent.com > > Cc: "Michael S. Tsirkin" <mst@redhat.com> > Cc: Jason Wang <jasowang@redhat.com> > Cc: Zi Yan <ziy@nvidia.com> > Cc: Gavin Shan <gshan@redhat.com> > Cc: Hui Zhu <teawater@gmail.com> > Cc: Eric Ren <renzhengeek@gmail.com> > Cc: Sebastien Boeuf <sebastien.boeuf@intel.com> > Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com> > Cc: Wei Yang <richard.weiyang@linux.alibaba.com> > Cc: virtualization@lists.linux-foundation.org > Cc: linux-mm@kvack.org > > David Hildenbrand (2): > virtio-mem: prepare page onlining code for granularity smaller than > MAX_ORDER - 1 > virtio-mem: prepare fake page onlining code for granularity smaller > than MAX_ORDER - 1 > > drivers/virtio/virtio_mem.c | 110 ++++++++++++++++++++++++------------ > 1 file changed, 74 insertions(+), 36 deletions(-) > > -- > 2.31.1
On 01.12.21 00:56, Michael S. Tsirkin wrote: > On Fri, Nov 26, 2021 at 02:42:07PM +0100, David Hildenbrand wrote: >> The virtio-mem driver currently supports logical hot(un)plug in >> MAX_ORDER - 1 granularity (4MiB on x86-64) or bigger. We want to support >> pageblock granularity (2MiB on x86-64), to make hot(un)plug even more >> flexible, and to improve hotunplug when using ZONE_NORMAL. >> >> With pageblock granularity, we then have a granularity comparable to >> hugepage ballooning. Further, there are ideas to increase MAX_ORDER, so >> we really want to decouple it from MAX_ORDER. >> >> While ZONE_MOVABLE should mostly work already, alloc_contig_range() still >> needs work to be able to properly handle pageblock granularity on >> ZONE_NORMAL. This support is in the works [1], so let's prepare >> virtio-mem for supporting smaller granularity than MAX_ORDER - 1. > > is there value to merging this seprately? or should this just > be part of that patchset? > The value would be to give it additional testing ahead of time. But we could just carry it along. Whatever you prefer. (I'd suggest merging it right away)