| Message ID | 20210622074926.333223-4-gshan@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm/page_reporting: Make page reporting work on arm64 with 64KB page size | expand |
On Mon, Jun 21, 2021 at 10:49 PM Gavin Shan <gshan@redhat.com> wrote: > > The page reporting won't be triggered if the freeing page can't come > up with a free area, whose size is equal or bigger than the threshold > (page reporting order). The default page reporting order, equal to > @pageblock_order, is too huge on some architectures to trigger page > reporting. One example is ARM64 when 64KB base page size is used. > > PAGE_SIZE: 64KB > pageblock_order: 13 (512MB) > MAX_ORDER: 14 > > This specifies the page reporting order to 5 (2MB) for this specific > case so that page reporting can be triggered. > > Cc: Michael S. Tsirkin <mst@redhat.com> > Cc: David Hildenbrand <david@redhat.com> > Cc: virtualization@lists.linux-foundation.org > Signed-off-by: Gavin Shan <gshan@redhat.com> > --- > drivers/virtio/virtio_balloon.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c > index 510e9318854d..fd419780cc23 100644 > --- a/drivers/virtio/virtio_balloon.c > +++ b/drivers/virtio/virtio_balloon.c > @@ -993,6 +993,23 @@ static int virtballoon_probe(struct virtio_device *vdev) > goto out_unregister_oom; > } > > + /* > + * The default page reporting order is @pageblock_order, which > + * corresponds to 512MB in size on ARM64 when 64KB base page > + * size is used. The page reporting won't be triggered if the > + * freeing page can't come up with a free area like that huge. > + * So we specify the page reporting order to 5, corresponding > + * to 2MB. It helps to avoid THP splitting if 4KB base page > + * size is used by host. > + * > + * Ideallh, the page reporting order is selected based on the "Ideally" > + * host's base page size. However, it needs more work to report > + * that value. The hardcoded order would be fine currently. > + */ > +#if defined(CONFIG_ARM64) && defined(CONFIG_ARM64_64K_PAGES) > + vb->pr_dev_info.order = 5; > +#endif > + > err = page_reporting_register(&vb->pr_dev_info); > if (err) > goto out_unregister_oom; This works for now. However my preference would be to look into seeing if we can add a value that the host can report that would override the value you selected here. Then in situations where the host has a smaller THP page size then the guest it can report the preferred reporting order via the virtio_balloon interface and have greater flexibility. Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
On 6/23/21 3:44 AM, Alexander Duyck wrote: > On Mon, Jun 21, 2021 at 10:49 PM Gavin Shan <gshan@redhat.com> wrote: >> >> The page reporting won't be triggered if the freeing page can't come >> up with a free area, whose size is equal or bigger than the threshold >> (page reporting order). The default page reporting order, equal to >> @pageblock_order, is too huge on some architectures to trigger page >> reporting. One example is ARM64 when 64KB base page size is used. >> >> PAGE_SIZE: 64KB >> pageblock_order: 13 (512MB) >> MAX_ORDER: 14 >> >> This specifies the page reporting order to 5 (2MB) for this specific >> case so that page reporting can be triggered. >> >> Cc: Michael S. Tsirkin <mst@redhat.com> >> Cc: David Hildenbrand <david@redhat.com> >> Cc: virtualization@lists.linux-foundation.org >> Signed-off-by: Gavin Shan <gshan@redhat.com> >> --- >> drivers/virtio/virtio_balloon.c | 17 +++++++++++++++++ >> 1 file changed, 17 insertions(+) >> >> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c >> index 510e9318854d..fd419780cc23 100644 >> --- a/drivers/virtio/virtio_balloon.c >> +++ b/drivers/virtio/virtio_balloon.c >> @@ -993,6 +993,23 @@ static int virtballoon_probe(struct virtio_device *vdev) >> goto out_unregister_oom; >> } >> >> + /* >> + * The default page reporting order is @pageblock_order, which >> + * corresponds to 512MB in size on ARM64 when 64KB base page >> + * size is used. The page reporting won't be triggered if the >> + * freeing page can't come up with a free area like that huge. >> + * So we specify the page reporting order to 5, corresponding >> + * to 2MB. It helps to avoid THP splitting if 4KB base page >> + * size is used by host. >> + * >> + * Ideallh, the page reporting order is selected based on the > > "Ideally" > Yeah, I noticed it right after the patch was posted. Will be fixed in v3. >> + * host's base page size. However, it needs more work to report >> + * that value. The hardcoded order would be fine currently. >> + */ >> +#if defined(CONFIG_ARM64) && defined(CONFIG_ARM64_64K_PAGES) >> + vb->pr_dev_info.order = 5; >> +#endif >> + >> err = page_reporting_register(&vb->pr_dev_info); >> if (err) >> goto out_unregister_oom; > > This works for now. However my preference would be to look into seeing > if we can add a value that the host can report that would override the > value you selected here. Then in situations where the host has a > smaller THP page size then the guest it can report the preferred > reporting order via the virtio_balloon interface and have greater > flexibility. > > Reviewed-by: Alexander Duyck <alexanderduyck@fb.com> > Yes, It's something for later. Lets fix the particular case (ARM64 and 64KB page size) for now. Thanks, Gavin
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index 510e9318854d..fd419780cc23 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -993,6 +993,23 @@ static int virtballoon_probe(struct virtio_device *vdev) goto out_unregister_oom; } + /* + * The default page reporting order is @pageblock_order, which + * corresponds to 512MB in size on ARM64 when 64KB base page + * size is used. The page reporting won't be triggered if the + * freeing page can't come up with a free area like that huge. + * So we specify the page reporting order to 5, corresponding + * to 2MB. It helps to avoid THP splitting if 4KB base page + * size is used by host. + * + * Ideallh, the page reporting order is selected based on the + * host's base page size. However, it needs more work to report + * that value. The hardcoded order would be fine currently. + */ +#if defined(CONFIG_ARM64) && defined(CONFIG_ARM64_64K_PAGES) + vb->pr_dev_info.order = 5; +#endif + err = page_reporting_register(&vb->pr_dev_info); if (err) goto out_unregister_oom;
The page reporting won't be triggered if the freeing page can't come up with a free area, whose size is equal or bigger than the threshold (page reporting order). The default page reporting order, equal to @pageblock_order, is too huge on some architectures to trigger page reporting. One example is ARM64 when 64KB base page size is used. PAGE_SIZE: 64KB pageblock_order: 13 (512MB) MAX_ORDER: 14 This specifies the page reporting order to 5 (2MB) for this specific case so that page reporting can be triggered. Cc: Michael S. Tsirkin <mst@redhat.com> Cc: David Hildenbrand <david@redhat.com> Cc: virtualization@lists.linux-foundation.org Signed-off-by: Gavin Shan <gshan@redhat.com> --- drivers/virtio/virtio_balloon.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)