| Message ID | 1529037793-35521-3-git-send-email-wei.w.wang@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jun 15, 2018 at 12:43:11PM +0800, Wei Wang wrote: > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_HINT feature indicates the > support of reporting hints of guest free pages to host via virtio-balloon. > > Host requests the guest to report free page hints by sending a command > to the guest via setting the VIRTIO_BALLOON_HOST_CMD_FREE_PAGE_HINT bit > of the host_cmd config register. > > As the first step here, virtio-balloon only reports free page hints from > the max order (10) free page list to host. This has generated similar good > results as reporting all free page hints during our tests. > > TODO: > - support reporting free page hints from smaller order free page lists > when there is a need/request from users. > > Signed-off-by: Wei Wang <wei.w.wang@intel.com> > Signed-off-by: Liang Li <liang.z.li@intel.com> > Cc: Michael S. Tsirkin <mst@redhat.com> > Cc: Michal Hocko <mhocko@kernel.org> > Cc: Andrew Morton <akpm@linux-foundation.org> > --- > drivers/virtio/virtio_balloon.c | 187 +++++++++++++++++++++++++++++------- > include/uapi/linux/virtio_balloon.h | 13 +++ > 2 files changed, 163 insertions(+), 37 deletions(-) > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c > index 6b237e3..582a03b 100644 > --- a/drivers/virtio/virtio_balloon.c > +++ b/drivers/virtio/virtio_balloon.c > @@ -43,6 +43,9 @@ > #define OOM_VBALLOON_DEFAULT_PAGES 256 > #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80 > > +/* The size of memory in bytes allocated for reporting free page hints */ > +#define FREE_PAGE_HINT_MEM_SIZE (PAGE_SIZE * 16) > + > static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES; > module_param(oom_pages, int, S_IRUSR | S_IWUSR); > MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); Doesn't this limit memory size of the guest we can report? Apparently to several gigabytes ... OTOH huge guests with lots of free memory is exactly where we would gain the most ...
On Friday, June 15, 2018 7:42 PM, Michael S. Tsirkin wrote: > On Fri, Jun 15, 2018 at 12:43:11PM +0800, Wei Wang wrote: > > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_HINT feature indicates > > the support of reporting hints of guest free pages to host via virtio-balloon. > > > > Host requests the guest to report free page hints by sending a command > > to the guest via setting the > VIRTIO_BALLOON_HOST_CMD_FREE_PAGE_HINT > > bit of the host_cmd config register. > > > > As the first step here, virtio-balloon only reports free page hints > > from the max order (10) free page list to host. This has generated > > similar good results as reporting all free page hints during our tests. > > > > TODO: > > - support reporting free page hints from smaller order free page lists > > when there is a need/request from users. > > > > Signed-off-by: Wei Wang <wei.w.wang@intel.com> > > Signed-off-by: Liang Li <liang.z.li@intel.com> > > Cc: Michael S. Tsirkin <mst@redhat.com> > > Cc: Michal Hocko <mhocko@kernel.org> > > Cc: Andrew Morton <akpm@linux-foundation.org> > > --- > > drivers/virtio/virtio_balloon.c | 187 +++++++++++++++++++++++++++++-- > ----- > > include/uapi/linux/virtio_balloon.h | 13 +++ > > 2 files changed, 163 insertions(+), 37 deletions(-) > > > > diff --git a/drivers/virtio/virtio_balloon.c > > b/drivers/virtio/virtio_balloon.c index 6b237e3..582a03b 100644 > > --- a/drivers/virtio/virtio_balloon.c > > +++ b/drivers/virtio/virtio_balloon.c > > @@ -43,6 +43,9 @@ > > #define OOM_VBALLOON_DEFAULT_PAGES 256 #define > > VIRTBALLOON_OOM_NOTIFY_PRIORITY 80 > > > > +/* The size of memory in bytes allocated for reporting free page > > +hints */ #define FREE_PAGE_HINT_MEM_SIZE (PAGE_SIZE * 16) > > + > > static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES; > > module_param(oom_pages, int, S_IRUSR | S_IWUSR); > > MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); > > Doesn't this limit memory size of the guest we can report? > Apparently to several gigabytes ... > OTOH huge guests with lots of free memory is exactly where we would gain > the most ... Yes, the 16-page array can report up to 32GB (each page can hold 512 addresses of 4MB free page blocks, i.e. 2GB free memory per page) free memory to host. It is not flexible. How about allocating the buffer according to the guest memory size (proportional)? That is, /* Calculates the maximum number of 4MB (equals to 1024 pages) free pages blocks that the system can have */ 4m_page_blocks = totalram_pages / 1024; /* Allocating one page can hold 512 free page blocks, so calculates the number of pages that can hold those 4MB blocks. And this allocation should not exceed 1024 pages */ pages_to_allocate = min(4m_page_blocks / 512, 1024); For a 2TB guests, which has 2^19 page blocks (4MB each), we will allocate 1024 pages as the buffer. When the guest has large memory, it should be easier to succeed in allocation of large buffer. If that allocation fails, that implies that nothing would be got from the 4MB free page list. I think the proportional allocation is simpler compared to other approaches like - scattered buffer, which will complicate the get_from_free_page_list implementation; - one buffer to call get_from_free_page_list multiple times, which needs get_from_free_page_list to maintain states.. also too complicated. Best, Wei
On Fri, Jun 15, 2018 at 02:11:23PM +0000, Wang, Wei W wrote: > On Friday, June 15, 2018 7:42 PM, Michael S. Tsirkin wrote: > > On Fri, Jun 15, 2018 at 12:43:11PM +0800, Wei Wang wrote: > > > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_HINT feature indicates > > > the support of reporting hints of guest free pages to host via virtio-balloon. > > > > > > Host requests the guest to report free page hints by sending a command > > > to the guest via setting the > > VIRTIO_BALLOON_HOST_CMD_FREE_PAGE_HINT > > > bit of the host_cmd config register. > > > > > > As the first step here, virtio-balloon only reports free page hints > > > from the max order (10) free page list to host. This has generated > > > similar good results as reporting all free page hints during our tests. > > > > > > TODO: > > > - support reporting free page hints from smaller order free page lists > > > when there is a need/request from users. > > > > > > Signed-off-by: Wei Wang <wei.w.wang@intel.com> > > > Signed-off-by: Liang Li <liang.z.li@intel.com> > > > Cc: Michael S. Tsirkin <mst@redhat.com> > > > Cc: Michal Hocko <mhocko@kernel.org> > > > Cc: Andrew Morton <akpm@linux-foundation.org> > > > --- > > > drivers/virtio/virtio_balloon.c | 187 +++++++++++++++++++++++++++++-- > > ----- > > > include/uapi/linux/virtio_balloon.h | 13 +++ > > > 2 files changed, 163 insertions(+), 37 deletions(-) > > > > > > diff --git a/drivers/virtio/virtio_balloon.c > > > b/drivers/virtio/virtio_balloon.c index 6b237e3..582a03b 100644 > > > --- a/drivers/virtio/virtio_balloon.c > > > +++ b/drivers/virtio/virtio_balloon.c > > > @@ -43,6 +43,9 @@ > > > #define OOM_VBALLOON_DEFAULT_PAGES 256 #define > > > VIRTBALLOON_OOM_NOTIFY_PRIORITY 80 > > > > > > +/* The size of memory in bytes allocated for reporting free page > > > +hints */ #define FREE_PAGE_HINT_MEM_SIZE (PAGE_SIZE * 16) > > > + > > > static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES; > > > module_param(oom_pages, int, S_IRUSR | S_IWUSR); > > > MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); > > > > Doesn't this limit memory size of the guest we can report? > > Apparently to several gigabytes ... > > OTOH huge guests with lots of free memory is exactly where we would gain > > the most ... > > Yes, the 16-page array can report up to 32GB (each page can hold 512 addresses of 4MB free page blocks, i.e. 2GB free memory per page) free memory to host. It is not flexible. > > How about allocating the buffer according to the guest memory size (proportional)? That is, > > /* Calculates the maximum number of 4MB (equals to 1024 pages) free pages blocks that the system can have */ > 4m_page_blocks = totalram_pages / 1024; > > /* Allocating one page can hold 512 free page blocks, so calculates the number of pages that can hold those 4MB blocks. And this allocation should not exceed 1024 pages */ > pages_to_allocate = min(4m_page_blocks / 512, 1024); > > For a 2TB guests, which has 2^19 page blocks (4MB each), we will allocate 1024 pages as the buffer. > > When the guest has large memory, it should be easier to succeed in allocation of large buffer. If that allocation fails, that implies that nothing would be got from the 4MB free page list. > > I think the proportional allocation is simpler compared to other approaches like > - scattered buffer, which will complicate the get_from_free_page_list implementation; > - one buffer to call get_from_free_page_list multiple times, which needs get_from_free_page_list to maintain states.. also too complicated. > > Best, > Wei > That's more reasonable, but question remains what to do if that value exceeds MAX_ORDER. I'd say maybe tell host we can't report it. Also allocating it with GFP_KERNEL is out. You only want to take it off the free list. So I guess __GFP_NOMEMALLOC and __GFP_ATOMIC. Also you can't allocate this on device start. First totalram_pages can change. Second that's too much memory to tie up forever.
On Friday, June 15, 2018 10:29 PM, Michael S. Tsirkin wrote: > On Fri, Jun 15, 2018 at 02:11:23PM +0000, Wang, Wei W wrote: > > On Friday, June 15, 2018 7:42 PM, Michael S. Tsirkin wrote: > > > On Fri, Jun 15, 2018 at 12:43:11PM +0800, Wei Wang wrote: > > > > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_HINT feature > > > > indicates the support of reporting hints of guest free pages to host via > virtio-balloon. > > > > > > > > Host requests the guest to report free page hints by sending a > > > > command to the guest via setting the > > > VIRTIO_BALLOON_HOST_CMD_FREE_PAGE_HINT > > > > bit of the host_cmd config register. > > > > > > > > As the first step here, virtio-balloon only reports free page > > > > hints from the max order (10) free page list to host. This has > > > > generated similar good results as reporting all free page hints during > our tests. > > > > > > > > TODO: > > > > - support reporting free page hints from smaller order free page lists > > > > when there is a need/request from users. > > > > > > > > Signed-off-by: Wei Wang <wei.w.wang@intel.com> > > > > Signed-off-by: Liang Li <liang.z.li@intel.com> > > > > Cc: Michael S. Tsirkin <mst@redhat.com> > > > > Cc: Michal Hocko <mhocko@kernel.org> > > > > Cc: Andrew Morton <akpm@linux-foundation.org> > > > > --- > > > > drivers/virtio/virtio_balloon.c | 187 > +++++++++++++++++++++++++++++-- > > > ----- > > > > include/uapi/linux/virtio_balloon.h | 13 +++ > > > > 2 files changed, 163 insertions(+), 37 deletions(-) > > > > > > > > diff --git a/drivers/virtio/virtio_balloon.c > > > > b/drivers/virtio/virtio_balloon.c index 6b237e3..582a03b 100644 > > > > --- a/drivers/virtio/virtio_balloon.c > > > > +++ b/drivers/virtio/virtio_balloon.c > > > > @@ -43,6 +43,9 @@ > > > > #define OOM_VBALLOON_DEFAULT_PAGES 256 #define > > > > VIRTBALLOON_OOM_NOTIFY_PRIORITY 80 > > > > > > > > +/* The size of memory in bytes allocated for reporting free page > > > > +hints */ #define FREE_PAGE_HINT_MEM_SIZE (PAGE_SIZE * 16) > > > > + > > > > static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES; > > > > module_param(oom_pages, int, S_IRUSR | S_IWUSR); > > > > MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); > > > > > > Doesn't this limit memory size of the guest we can report? > > > Apparently to several gigabytes ... > > > OTOH huge guests with lots of free memory is exactly where we would > > > gain the most ... > > > > Yes, the 16-page array can report up to 32GB (each page can hold 512 > addresses of 4MB free page blocks, i.e. 2GB free memory per page) free > memory to host. It is not flexible. > > > > How about allocating the buffer according to the guest memory size > > (proportional)? That is, > > > > /* Calculates the maximum number of 4MB (equals to 1024 pages) free > > pages blocks that the system can have */ 4m_page_blocks = > > totalram_pages / 1024; > > > > /* Allocating one page can hold 512 free page blocks, so calculates > > the number of pages that can hold those 4MB blocks. And this > > allocation should not exceed 1024 pages */ pages_to_allocate = > > min(4m_page_blocks / 512, 1024); > > > > For a 2TB guests, which has 2^19 page blocks (4MB each), we will allocate > 1024 pages as the buffer. > > > > When the guest has large memory, it should be easier to succeed in > allocation of large buffer. If that allocation fails, that implies that nothing > would be got from the 4MB free page list. > > > > I think the proportional allocation is simpler compared to other > > approaches like > > - scattered buffer, which will complicate the get_from_free_page_list > > implementation; > > - one buffer to call get_from_free_page_list multiple times, which needs > get_from_free_page_list to maintain states.. also too complicated. > > > > Best, > > Wei > > > > That's more reasonable, but question remains what to do if that value > exceeds MAX_ORDER. I'd say maybe tell host we can't report it. Not necessarily, I think. We have min(4m_page_blocks / 512, 1024) above, so the maximum memory that can be reported is 2TB. For larger guests, e.g. 4TB, the optimization can still offer 2TB free memory (better than no optimization). On the other hand, large guests being large mostly because the guests need to use large memory. In that case, they usually won't have that much free memory to report. > > Also allocating it with GFP_KERNEL is out. You only want to take it off the free > list. So I guess __GFP_NOMEMALLOC and __GFP_ATOMIC. Sounds good, thanks. > Also you can't allocate this on device start. First totalram_pages can change. > Second that's too much memory to tie up forever. Yes, makes sense. Best, Wei
On Sat, Jun 16, 2018 at 01:09:44AM +0000, Wang, Wei W wrote: > On Friday, June 15, 2018 10:29 PM, Michael S. Tsirkin wrote: > > On Fri, Jun 15, 2018 at 02:11:23PM +0000, Wang, Wei W wrote: > > > On Friday, June 15, 2018 7:42 PM, Michael S. Tsirkin wrote: > > > > On Fri, Jun 15, 2018 at 12:43:11PM +0800, Wei Wang wrote: > > > > > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_HINT feature > > > > > indicates the support of reporting hints of guest free pages to host via > > virtio-balloon. > > > > > > > > > > Host requests the guest to report free page hints by sending a > > > > > command to the guest via setting the > > > > VIRTIO_BALLOON_HOST_CMD_FREE_PAGE_HINT > > > > > bit of the host_cmd config register. > > > > > > > > > > As the first step here, virtio-balloon only reports free page > > > > > hints from the max order (10) free page list to host. This has > > > > > generated similar good results as reporting all free page hints during > > our tests. > > > > > > > > > > TODO: > > > > > - support reporting free page hints from smaller order free page lists > > > > > when there is a need/request from users. > > > > > > > > > > Signed-off-by: Wei Wang <wei.w.wang@intel.com> > > > > > Signed-off-by: Liang Li <liang.z.li@intel.com> > > > > > Cc: Michael S. Tsirkin <mst@redhat.com> > > > > > Cc: Michal Hocko <mhocko@kernel.org> > > > > > Cc: Andrew Morton <akpm@linux-foundation.org> > > > > > --- > > > > > drivers/virtio/virtio_balloon.c | 187 > > +++++++++++++++++++++++++++++-- > > > > ----- > > > > > include/uapi/linux/virtio_balloon.h | 13 +++ > > > > > 2 files changed, 163 insertions(+), 37 deletions(-) > > > > > > > > > > diff --git a/drivers/virtio/virtio_balloon.c > > > > > b/drivers/virtio/virtio_balloon.c index 6b237e3..582a03b 100644 > > > > > --- a/drivers/virtio/virtio_balloon.c > > > > > +++ b/drivers/virtio/virtio_balloon.c > > > > > @@ -43,6 +43,9 @@ > > > > > #define OOM_VBALLOON_DEFAULT_PAGES 256 #define > > > > > VIRTBALLOON_OOM_NOTIFY_PRIORITY 80 > > > > > > > > > > +/* The size of memory in bytes allocated for reporting free page > > > > > +hints */ #define FREE_PAGE_HINT_MEM_SIZE (PAGE_SIZE * 16) > > > > > + > > > > > static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES; > > > > > module_param(oom_pages, int, S_IRUSR | S_IWUSR); > > > > > MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); > > > > > > > > Doesn't this limit memory size of the guest we can report? > > > > Apparently to several gigabytes ... > > > > OTOH huge guests with lots of free memory is exactly where we would > > > > gain the most ... > > > > > > Yes, the 16-page array can report up to 32GB (each page can hold 512 > > addresses of 4MB free page blocks, i.e. 2GB free memory per page) free > > memory to host. It is not flexible. > > > > > > How about allocating the buffer according to the guest memory size > > > (proportional)? That is, > > > > > > /* Calculates the maximum number of 4MB (equals to 1024 pages) free > > > pages blocks that the system can have */ 4m_page_blocks = > > > totalram_pages / 1024; > > > > > > /* Allocating one page can hold 512 free page blocks, so calculates > > > the number of pages that can hold those 4MB blocks. And this > > > allocation should not exceed 1024 pages */ pages_to_allocate = > > > min(4m_page_blocks / 512, 1024); > > > > > > For a 2TB guests, which has 2^19 page blocks (4MB each), we will allocate > > 1024 pages as the buffer. > > > > > > When the guest has large memory, it should be easier to succeed in > > allocation of large buffer. If that allocation fails, that implies that nothing > > would be got from the 4MB free page list. > > > > > > I think the proportional allocation is simpler compared to other > > > approaches like > > > - scattered buffer, which will complicate the get_from_free_page_list > > > implementation; > > > - one buffer to call get_from_free_page_list multiple times, which needs > > get_from_free_page_list to maintain states.. also too complicated. > > > > > > Best, > > > Wei > > > > > > > That's more reasonable, but question remains what to do if that value > > exceeds MAX_ORDER. I'd say maybe tell host we can't report it. > > Not necessarily, I think. We have min(4m_page_blocks / 512, 1024) above, so the maximum memory that can be reported is 2TB. For larger guests, e.g. 4TB, the optimization can still offer 2TB free memory (better than no optimization). Maybe it's better, maybe it isn't. It certainly muddies the waters even more. I'd rather we had a better plan. From that POV I like what Matthew Wilcox suggested for this which is to steal the necessary # of entries off the list. If that doesn't fly, we can allocate out of the loop and just retry with more pages. > On the other hand, large guests being large mostly because the guests need to use large memory. In that case, they usually won't have that much free memory to report. And following this logic small guests don't have a lot of memory to report at all. Could you remind me why are we considering this optimization then? > > > > Also allocating it with GFP_KERNEL is out. You only want to take it off the free > > list. So I guess __GFP_NOMEMALLOC and __GFP_ATOMIC. > > Sounds good, thanks. > > > Also you can't allocate this on device start. First totalram_pages can change. > > Second that's too much memory to tie up forever. > > Yes, makes sense. > > Best, > Wei
On Monday, June 18, 2018 10:29 AM, Michael S. Tsirkin wrote: > On Sat, Jun 16, 2018 at 01:09:44AM +0000, Wang, Wei W wrote: > > Not necessarily, I think. We have min(4m_page_blocks / 512, 1024) above, > so the maximum memory that can be reported is 2TB. For larger guests, e.g. > 4TB, the optimization can still offer 2TB free memory (better than no > optimization). > > Maybe it's better, maybe it isn't. It certainly muddies the waters even more. > I'd rather we had a better plan. From that POV I like what Matthew Wilcox > suggested for this which is to steal the necessary # of entries off the list. Actually what Matthew suggested doesn't make a difference here. That method always steal the first free page blocks, and sure can be changed to take more. But all these can be achieved via kmalloc by the caller which is more prudent and makes the code more straightforward. I think we don't need to take that risk unless the MM folks strongly endorse that approach. The max size of the kmalloc-ed memory is 4MB, which gives us the limitation that the max free memory to report is 2TB. Back to the motivation of this work, the cloud guys want to use this optimization to accelerate their guest live migration. 2TB guests are not common in today's clouds. When huge guests become common in the future, we can easily tweak this API to fill hints into scattered buffer (e.g. several 4MB arrays passed to this API) instead of one as in this version. This limitation doesn't cause any issue from functionality perspective. For the extreme case like a 100TB guest live migration which is theoretically possible today, this optimization helps skip 2TB of its free memory. This result is that it may reduce only 2% live migration time, but still better than not skipping the 2TB (if not using the feature). So, for the first release of this feature, I think it is better to have the simpler and more straightforward solution as we have now, and clearly document why it can report up to 2TB free memory. > If that doesn't fly, we can allocate out of the loop and just retry with more > pages. > > > On the other hand, large guests being large mostly because the guests need > to use large memory. In that case, they usually won't have that much free > memory to report. > > And following this logic small guests don't have a lot of memory to report at > all. > Could you remind me why are we considering this optimization then? If there is a 3TB guest, it is 3TB not 2TB mostly because it would need to use e.g. 2.5TB memory from time to time. In the worst case, it only has 0.5TB free memory to report, but reporting 0.5TB with this optimization is better than no optimization. (and the current 2TB limitation isn't a limitation for the 3TB guest in this case) Best, Wei
On Tue, Jun 19, 2018 at 01:06:48AM +0000, Wang, Wei W wrote: > On Monday, June 18, 2018 10:29 AM, Michael S. Tsirkin wrote: > > On Sat, Jun 16, 2018 at 01:09:44AM +0000, Wang, Wei W wrote: > > > Not necessarily, I think. We have min(4m_page_blocks / 512, 1024) above, > > so the maximum memory that can be reported is 2TB. For larger guests, e.g. > > 4TB, the optimization can still offer 2TB free memory (better than no > > optimization). > > > > Maybe it's better, maybe it isn't. It certainly muddies the waters even more. > > I'd rather we had a better plan. From that POV I like what Matthew Wilcox > > suggested for this which is to steal the necessary # of entries off the list. > > Actually what Matthew suggested doesn't make a difference here. That method always steal the first free page blocks, and sure can be changed to take more. But all these can be achieved via kmalloc I'd do get_user_pages really. You don't want pages split, etc. > by the caller which is more prudent and makes the code more straightforward. I think we don't need to take that risk unless the MM folks strongly endorse that approach. > > The max size of the kmalloc-ed memory is 4MB, which gives us the limitation that the max free memory to report is 2TB. Back to the motivation of this work, the cloud guys want to use this optimization to accelerate their guest live migration. 2TB guests are not common in today's clouds. When huge guests become common in the future, we can easily tweak this API to fill hints into scattered buffer (e.g. several 4MB arrays passed to this API) instead of one as in this version. > > This limitation doesn't cause any issue from functionality perspective. For the extreme case like a 100TB guest live migration which is theoretically possible today, this optimization helps skip 2TB of its free memory. This result is that it may reduce only 2% live migration time, but still better than not skipping the 2TB (if not using the feature). Not clearly better, no, since you are slowing the guest. > So, for the first release of this feature, I think it is better to have the simpler and more straightforward solution as we have now, and clearly document why it can report up to 2TB free memory. No one has the time to read documentation about how an internal flag within a device works. Come on, getting two pages isn't much harder than a single one. > > > > If that doesn't fly, we can allocate out of the loop and just retry with more > > pages. > > > > > On the other hand, large guests being large mostly because the guests need > > to use large memory. In that case, they usually won't have that much free > > memory to report. > > > > And following this logic small guests don't have a lot of memory to report at > > all. > > Could you remind me why are we considering this optimization then? > > If there is a 3TB guest, it is 3TB not 2TB mostly because it would need to use e.g. 2.5TB memory from time to time. In the worst case, it only has 0.5TB free memory to report, but reporting 0.5TB with this optimization is better than no optimization. (and the current 2TB limitation isn't a limitation for the 3TB guest in this case) I'd rather not spend time writing up random limitations. > Best, > Wei
On 06/19/2018 11:05 AM, Michael S. Tsirkin wrote: > On Tue, Jun 19, 2018 at 01:06:48AM +0000, Wang, Wei W wrote: >> On Monday, June 18, 2018 10:29 AM, Michael S. Tsirkin wrote: >>> On Sat, Jun 16, 2018 at 01:09:44AM +0000, Wang, Wei W wrote: >>>> Not necessarily, I think. We have min(4m_page_blocks / 512, 1024) above, >>> so the maximum memory that can be reported is 2TB. For larger guests, e.g. >>> 4TB, the optimization can still offer 2TB free memory (better than no >>> optimization). >>> >>> Maybe it's better, maybe it isn't. It certainly muddies the waters even more. >>> I'd rather we had a better plan. From that POV I like what Matthew Wilcox >>> suggested for this which is to steal the necessary # of entries off the list. >> Actually what Matthew suggested doesn't make a difference here. That method always steal the first free page blocks, and sure can be changed to take more. But all these can be achieved via kmalloc > I'd do get_user_pages really. You don't want pages split, etc. >> by the caller which is more prudent and makes the code more straightforward. I think we don't need to take that risk unless the MM folks strongly endorse that approach. >> >> The max size of the kmalloc-ed memory is 4MB, which gives us the limitation that the max free memory to report is 2TB. Back to the motivation of this work, the cloud guys want to use this optimization to accelerate their guest live migration. 2TB guests are not common in today's clouds. When huge guests become common in the future, we can easily tweak this API to fill hints into scattered buffer (e.g. several 4MB arrays passed to this API) instead of one as in this version. >> >> This limitation doesn't cause any issue from functionality perspective. For the extreme case like a 100TB guest live migration which is theoretically possible today, this optimization helps skip 2TB of its free memory. This result is that it may reduce only 2% live migration time, but still better than not skipping the 2TB (if not using the feature). > Not clearly better, no, since you are slowing the guest. Not really. Live migration slows down the guest itself. It seems that the guest spends a little extra time reporting free pages, but in return the live migration time gets reduced a lot, which makes the guest endure less from live migration. (there is no drop of the workload performance when using the optimization in the tests) > > >> So, for the first release of this feature, I think it is better to have the simpler and more straightforward solution as we have now, and clearly document why it can report up to 2TB free memory. > No one has the time to read documentation about how an internal flag > within a device works. Come on, getting two pages isn't much harder > than a single one. >> >>> If that doesn't fly, we can allocate out of the loop and just retry with more >>> pages. >>> >>>> On the other hand, large guests being large mostly because the guests need >>> to use large memory. In that case, they usually won't have that much free >>> memory to report. >>> >>> And following this logic small guests don't have a lot of memory to report at >>> all. >>> Could you remind me why are we considering this optimization then? >> If there is a 3TB guest, it is 3TB not 2TB mostly because it would need to use e.g. 2.5TB memory from time to time. In the worst case, it only has 0.5TB free memory to report, but reporting 0.5TB with this optimization is better than no optimization. (and the current 2TB limitation isn't a limitation for the 3TB guest in this case) > I'd rather not spend time writing up random limitations. This is not a random limitation. It would be more clear to see the code. Also I'm not sure how get_user_pages could be used in our case, and what you meant by "getting two pages". I'll post out a new version, and we can discuss on the code. Best, Wei
On Tue, Jun 19, 2018 at 08:13:37PM +0800, Wei Wang wrote: > On 06/19/2018 11:05 AM, Michael S. Tsirkin wrote: > > On Tue, Jun 19, 2018 at 01:06:48AM +0000, Wang, Wei W wrote: > > > On Monday, June 18, 2018 10:29 AM, Michael S. Tsirkin wrote: > > > > On Sat, Jun 16, 2018 at 01:09:44AM +0000, Wang, Wei W wrote: > > > > > Not necessarily, I think. We have min(4m_page_blocks / 512, 1024) above, > > > > so the maximum memory that can be reported is 2TB. For larger guests, e.g. > > > > 4TB, the optimization can still offer 2TB free memory (better than no > > > > optimization). > > > > > > > > Maybe it's better, maybe it isn't. It certainly muddies the waters even more. > > > > I'd rather we had a better plan. From that POV I like what Matthew Wilcox > > > > suggested for this which is to steal the necessary # of entries off the list. > > > Actually what Matthew suggested doesn't make a difference here. That method always steal the first free page blocks, and sure can be changed to take more. But all these can be achieved via kmalloc > > I'd do get_user_pages really. You don't want pages split, etc. Oops sorry. I meant get_free_pages . > > > > by the caller which is more prudent and makes the code more straightforward. I think we don't need to take that risk unless the MM folks strongly endorse that approach. > > > > > > The max size of the kmalloc-ed memory is 4MB, which gives us the limitation that the max free memory to report is 2TB. Back to the motivation of this work, the cloud guys want to use this optimization to accelerate their guest live migration. 2TB guests are not common in today's clouds. When huge guests become common in the future, we can easily tweak this API to fill hints into scattered buffer (e.g. several 4MB arrays passed to this API) instead of one as in this version. > > > > > > This limitation doesn't cause any issue from functionality perspective. For the extreme case like a 100TB guest live migration which is theoretically possible today, this optimization helps skip 2TB of its free memory. This result is that it may reduce only 2% live migration time, but still better than not skipping the 2TB (if not using the feature). > > Not clearly better, no, since you are slowing the guest. > > Not really. Live migration slows down the guest itself. It seems that the > guest spends a little extra time reporting free pages, but in return the > live migration time gets reduced a lot, which makes the guest endure less > from live migration. (there is no drop of the workload performance when > using the optimization in the tests) My point was you can't say what is better without measuring. Without special limitations you have hint overhead vs migration overhead. I think we need to build to scale to huge guests. We might discover scalability problems down the road, but no sense in building in limitations straight away. > > > > > > > > > So, for the first release of this feature, I think it is better to have the simpler and more straightforward solution as we have now, and clearly document why it can report up to 2TB free memory. > > No one has the time to read documentation about how an internal flag > > within a device works. Come on, getting two pages isn't much harder > > than a single one. > > > > > If that doesn't fly, we can allocate out of the loop and just retry with more > > > > pages. > > > > > > > > > On the other hand, large guests being large mostly because the guests need > > > > to use large memory. In that case, they usually won't have that much free > > > > memory to report. > > > > > > > > And following this logic small guests don't have a lot of memory to report at > > > > all. > > > > Could you remind me why are we considering this optimization then? > > > If there is a 3TB guest, it is 3TB not 2TB mostly because it would need to use e.g. 2.5TB memory from time to time. In the worst case, it only has 0.5TB free memory to report, but reporting 0.5TB with this optimization is better than no optimization. (and the current 2TB limitation isn't a limitation for the 3TB guest in this case) > > I'd rather not spend time writing up random limitations. > > This is not a random limitation. It would be more clear to see the code. Users don't see code though, that's the point. Exporting internal limitations from code to users isn't great. > Also I'm not sure how get_user_pages could be used in our case, and what you > meant by "getting two pages". I'll post out a new version, and we can > discuss on the code. Sorry, I meant get_free_pages. > > Best, > Wei
On Tuesday, June 19, 2018 10:43 PM, Michael S. Tsirk wrote: > On Tue, Jun 19, 2018 at 08:13:37PM +0800, Wei Wang wrote: > > On 06/19/2018 11:05 AM, Michael S. Tsirkin wrote: > > > On Tue, Jun 19, 2018 at 01:06:48AM +0000, Wang, Wei W wrote: > > > > On Monday, June 18, 2018 10:29 AM, Michael S. Tsirkin wrote: > > > > > On Sat, Jun 16, 2018 at 01:09:44AM +0000, Wang, Wei W wrote: > > > > > > Not necessarily, I think. We have min(4m_page_blocks / 512, > > > > > > 1024) above, > > > > > so the maximum memory that can be reported is 2TB. For larger > guests, e.g. > > > > > 4TB, the optimization can still offer 2TB free memory (better > > > > > than no optimization). > > > > > > > > > > Maybe it's better, maybe it isn't. It certainly muddies the waters even > more. > > > > > I'd rather we had a better plan. From that POV I like what > > > > > Matthew Wilcox suggested for this which is to steal the necessary # of > entries off the list. > > > > Actually what Matthew suggested doesn't make a difference here. > > > > That method always steal the first free page blocks, and sure can > > > > be changed to take more. But all these can be achieved via kmalloc > > > I'd do get_user_pages really. You don't want pages split, etc. > > Oops sorry. I meant get_free_pages . Yes, we can use __get_free_pages, and the max allocation is MAX_ORDER - 1, which can report up to 2TB free memory. "getting two pages isn't harder", do you mean passing two arrays (two allocations by get_free_pages(,MAX_ORDER -1)) to the mm API? Please see if the following logic aligns to what you think: uint32_t i, max_hints, hints_per_page, hints_per_array, total_arrays; unsigned long *arrays; /* * Each array size is MAX_ORDER_NR_PAGES. If one array is not enough to * store all the hints, we need to allocate multiple arrays. * max_hints: the max number of 4MB free page blocks * hints_per_page: the number of hints each page can store * hints_per_array: the number of hints an array can store * total_arrays: the number of arrays we need */ max_hints = totalram_pages / MAX_ORDER_NR_PAGES; hints_per_page = PAGE_SIZE / sizeof(__le64); hints_per_array = hints_per_page * MAX_ORDER_NR_PAGES; total_arrays = max_hints / hints_per_array + !!(max_hints % hints_per_array); arrays = kmalloc(total_arrays * sizeof(unsigned long), GFP_KERNEL); for (i = 0; i < total_arrays; i++) { arrays[i] = __get_free_pages(__GFP_ATOMIC | __GFP_NOMEMALLOC, MAX_ORDER - 1); if (!arrays[i]) goto out; } - the mm API needs to be changed to support storing hints to multiple separated arrays offered by the caller. Best, Wei
On Wed, Jun 20, 2018 at 09:11:39AM +0000, Wang, Wei W wrote: > On Tuesday, June 19, 2018 10:43 PM, Michael S. Tsirk wrote: > > On Tue, Jun 19, 2018 at 08:13:37PM +0800, Wei Wang wrote: > > > On 06/19/2018 11:05 AM, Michael S. Tsirkin wrote: > > > > On Tue, Jun 19, 2018 at 01:06:48AM +0000, Wang, Wei W wrote: > > > > > On Monday, June 18, 2018 10:29 AM, Michael S. Tsirkin wrote: > > > > > > On Sat, Jun 16, 2018 at 01:09:44AM +0000, Wang, Wei W wrote: > > > > > > > Not necessarily, I think. We have min(4m_page_blocks / 512, > > > > > > > 1024) above, > > > > > > so the maximum memory that can be reported is 2TB. For larger > > guests, e.g. > > > > > > 4TB, the optimization can still offer 2TB free memory (better > > > > > > than no optimization). > > > > > > > > > > > > Maybe it's better, maybe it isn't. It certainly muddies the waters even > > more. > > > > > > I'd rather we had a better plan. From that POV I like what > > > > > > Matthew Wilcox suggested for this which is to steal the necessary # of > > entries off the list. > > > > > Actually what Matthew suggested doesn't make a difference here. > > > > > That method always steal the first free page blocks, and sure can > > > > > be changed to take more. But all these can be achieved via kmalloc > > > > I'd do get_user_pages really. You don't want pages split, etc. > > > > Oops sorry. I meant get_free_pages . > > Yes, we can use __get_free_pages, and the max allocation is MAX_ORDER - 1, which can report up to 2TB free memory. > > "getting two pages isn't harder", do you mean passing two arrays (two allocations by get_free_pages(,MAX_ORDER -1)) to the mm API? Yes, or generally a list of pages with as many as needed. > Please see if the following logic aligns to what you think: > > uint32_t i, max_hints, hints_per_page, hints_per_array, total_arrays; > unsigned long *arrays; > > /* > * Each array size is MAX_ORDER_NR_PAGES. If one array is not enough to > * store all the hints, we need to allocate multiple arrays. > * max_hints: the max number of 4MB free page blocks > * hints_per_page: the number of hints each page can store > * hints_per_array: the number of hints an array can store > * total_arrays: the number of arrays we need > */ > max_hints = totalram_pages / MAX_ORDER_NR_PAGES; > hints_per_page = PAGE_SIZE / sizeof(__le64); > hints_per_array = hints_per_page * MAX_ORDER_NR_PAGES; > total_arrays = max_hints / hints_per_array + > !!(max_hints % hints_per_array); > arrays = kmalloc(total_arrays * sizeof(unsigned long), GFP_KERNEL); > for (i = 0; i < total_arrays; i++) { > arrays[i] = __get_free_pages(__GFP_ATOMIC | __GFP_NOMEMALLOC, MAX_ORDER - 1); > > if (!arrays[i]) > goto out; > } > > > - the mm API needs to be changed to support storing hints to multiple separated arrays offered by the caller. > > Best, > Wei Yes. And add an API to just count entries so we know how many arrays to allocate.
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index 6b237e3..582a03b 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -43,6 +43,9 @@ #define OOM_VBALLOON_DEFAULT_PAGES 256 #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80 +/* The size of memory in bytes allocated for reporting free page hints */ +#define FREE_PAGE_HINT_MEM_SIZE (PAGE_SIZE * 16) + static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES; module_param(oom_pages, int, S_IRUSR | S_IWUSR); MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); @@ -51,9 +54,22 @@ MODULE_PARM_DESC(oom_pages, "pages to free on OOM"); static struct vfsmount *balloon_mnt; #endif +enum virtio_balloon_vq { + VIRTIO_BALLOON_VQ_INFLATE, + VIRTIO_BALLOON_VQ_DEFLATE, + VIRTIO_BALLOON_VQ_STATS, + VIRTIO_BALLOON_VQ_FREE_PAGE, + VIRTIO_BALLOON_VQ_MAX +}; + struct virtio_balloon { struct virtio_device *vdev; - struct virtqueue *inflate_vq, *deflate_vq, *stats_vq; + struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq; + + /* Balloon's own wq for cpu-intensive work items */ + struct workqueue_struct *balloon_wq; + /* The free page reporting work item submitted to the balloon wq */ + struct work_struct report_free_page_work; /* The balloon servicing is delegated to a freezable workqueue. */ struct work_struct update_balloon_stats_work; @@ -63,6 +79,8 @@ struct virtio_balloon { spinlock_t stop_update_lock; bool stop_update; + struct virtio_balloon_free_page_hints *hints; + /* Waiting for host to ack the pages we released. */ wait_queue_head_t acked; @@ -326,17 +344,6 @@ static void stats_handle_request(struct virtio_balloon *vb) virtqueue_kick(vq); } -static void virtballoon_changed(struct virtio_device *vdev) -{ - struct virtio_balloon *vb = vdev->priv; - unsigned long flags; - - spin_lock_irqsave(&vb->stop_update_lock, flags); - if (!vb->stop_update) - queue_work(system_freezable_wq, &vb->update_balloon_size_work); - spin_unlock_irqrestore(&vb->stop_update_lock, flags); -} - static inline s64 towards_target(struct virtio_balloon *vb) { s64 target; @@ -353,6 +360,32 @@ static inline s64 towards_target(struct virtio_balloon *vb) return target - vb->num_pages; } +static void virtballoon_changed(struct virtio_device *vdev) +{ + struct virtio_balloon *vb = vdev->priv; + unsigned long flags; + uint32_t host_cmd; + s64 diff = towards_target(vb); + + if (diff) { + spin_lock_irqsave(&vb->stop_update_lock, flags); + if (!vb->stop_update) + queue_work(system_freezable_wq, + &vb->update_balloon_size_work); + spin_unlock_irqrestore(&vb->stop_update_lock, flags); + } + + virtio_cread(vdev, struct virtio_balloon_config, host_cmd, &host_cmd); + if ((host_cmd & VIRTIO_BALLOON_HOST_CMD_FREE_PAGE_HINT) && + virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) { + spin_lock_irqsave(&vb->stop_update_lock, flags); + if (!vb->stop_update) + queue_work(vb->balloon_wq, + &vb->report_free_page_work); + spin_unlock_irqrestore(&vb->stop_update_lock, flags); + } +} + static void update_balloon_size(struct virtio_balloon *vb) { u32 actual = vb->num_pages; @@ -425,44 +458,98 @@ static void update_balloon_size_func(struct work_struct *work) queue_work(system_freezable_wq, work); } +static void free_page_vq_cb(struct virtqueue *vq) +{ + unsigned int unused; + + while (virtqueue_get_buf(vq, &unused)) + ; +} + static int init_vqs(struct virtio_balloon *vb) { - struct virtqueue *vqs[3]; - vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request }; - static const char * const names[] = { "inflate", "deflate", "stats" }; - int err, nvqs; + struct virtqueue *vqs[VIRTIO_BALLOON_VQ_MAX]; + vq_callback_t *callbacks[VIRTIO_BALLOON_VQ_MAX]; + const char *names[VIRTIO_BALLOON_VQ_MAX]; + struct scatterlist sg; + int ret; /* - * We expect two virtqueues: inflate and deflate, and - * optionally stat. + * Inflateq and deflateq are used unconditionally. The names[] + * will be NULL if the related feature is not enabled, which will + * cause no allocation for the corresponding virtqueue in find_vqs. */ - nvqs = virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ) ? 3 : 2; - err = virtio_find_vqs(vb->vdev, nvqs, vqs, callbacks, names, NULL); - if (err) - return err; + callbacks[VIRTIO_BALLOON_VQ_INFLATE] = balloon_ack; + names[VIRTIO_BALLOON_VQ_INFLATE] = "inflate"; + callbacks[VIRTIO_BALLOON_VQ_DEFLATE] = balloon_ack; + names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate"; + names[VIRTIO_BALLOON_VQ_STATS] = NULL; + names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL; - vb->inflate_vq = vqs[0]; - vb->deflate_vq = vqs[1]; if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) { - struct scatterlist sg; - unsigned int num_stats; - vb->stats_vq = vqs[2]; + names[VIRTIO_BALLOON_VQ_STATS] = "stats"; + callbacks[VIRTIO_BALLOON_VQ_STATS] = stats_request; + } + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) { + names[VIRTIO_BALLOON_VQ_FREE_PAGE] = "free_page_vq"; + callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = free_page_vq_cb; + } + + ret = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX, + vqs, callbacks, names, NULL, NULL); + if (ret) + return ret; + + vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE]; + vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE]; + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) { + vb->stats_vq = vqs[VIRTIO_BALLOON_VQ_STATS]; /* * Prime this virtqueue with one buffer so the hypervisor can * use it to signal us later (it can't be broken yet!). */ - num_stats = update_balloon_stats(vb); - - sg_init_one(&sg, vb->stats, sizeof(vb->stats[0]) * num_stats); - if (virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb, GFP_KERNEL) - < 0) - BUG(); + sg_init_one(&sg, vb->stats, sizeof(vb->stats)); + ret = virtqueue_add_outbuf(vb->stats_vq, &sg, 1, vb, + GFP_KERNEL); + if (ret) { + dev_warn(&vb->vdev->dev, "%s: add stat_vq failed\n", + __func__); + return ret; + } virtqueue_kick(vb->stats_vq); } + + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) + vb->free_page_vq = vqs[VIRTIO_BALLOON_VQ_FREE_PAGE]; + return 0; } +static void report_free_page_func(struct work_struct *work) +{ + struct virtio_balloon *vb; + struct virtqueue *vq; + struct virtio_balloon_free_page_hints *hints; + struct scatterlist sg; + uint32_t hdr_size, avail_entries, added_entries; + + vb = container_of(work, struct virtio_balloon, report_free_page_work); + vq = vb->free_page_vq; + hints = vb->hints; + hdr_size = sizeof(hints->num_hints) + sizeof(hints->size); + avail_entries = (FREE_PAGE_HINT_MEM_SIZE - hdr_size) / sizeof(__le64); + + added_entries = get_from_free_page_list(MAX_ORDER - 1, hints->buf, + avail_entries); + hints->num_hints = cpu_to_le32(added_entries); + hints->size = cpu_to_le32((1 << (MAX_ORDER - 1)) << PAGE_SHIFT); + + sg_init_one(&sg, vb->hints, FREE_PAGE_HINT_MEM_SIZE); + virtqueue_add_outbuf(vq, &sg, 1, vb->hints, GFP_KERNEL); + virtqueue_kick(vb->free_page_vq); +} + #ifdef CONFIG_BALLOON_COMPACTION /* * virtballoon_migratepage - perform the balloon page migration on behalf of @@ -576,18 +663,33 @@ static int virtballoon_probe(struct virtio_device *vdev) if (err) goto out_free_vb; + if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) { + vb->balloon_wq = alloc_workqueue("balloon-wq", + WQ_FREEZABLE | WQ_CPU_INTENSIVE, 0); + if (!vb->balloon_wq) { + err = -ENOMEM; + goto out_del_vqs; + } + INIT_WORK(&vb->report_free_page_work, report_free_page_func); + vb->hints = kmalloc(FREE_PAGE_HINT_MEM_SIZE, GFP_KERNEL); + if (!vb->hints) { + err = -ENOMEM; + goto out_del_balloon_wq; + } + } + vb->nb.notifier_call = virtballoon_oom_notify; vb->nb.priority = VIRTBALLOON_OOM_NOTIFY_PRIORITY; err = register_oom_notifier(&vb->nb); if (err < 0) - goto out_del_vqs; + goto out_del_free_page_hint; #ifdef CONFIG_BALLOON_COMPACTION balloon_mnt = kern_mount(&balloon_fs); if (IS_ERR(balloon_mnt)) { err = PTR_ERR(balloon_mnt); unregister_oom_notifier(&vb->nb); - goto out_del_vqs; + goto out_del_free_page_hint; } vb->vb_dev_info.migratepage = virtballoon_migratepage; @@ -597,7 +699,7 @@ static int virtballoon_probe(struct virtio_device *vdev) kern_unmount(balloon_mnt); unregister_oom_notifier(&vb->nb); vb->vb_dev_info.inode = NULL; - goto out_del_vqs; + goto out_del_free_page_hint; } vb->vb_dev_info.inode->i_mapping->a_ops = &balloon_aops; #endif @@ -607,7 +709,12 @@ static int virtballoon_probe(struct virtio_device *vdev) if (towards_target(vb)) virtballoon_changed(vdev); return 0; - +out_del_free_page_hint: + if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) + kfree(vb->hints); +out_del_balloon_wq: + if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) + destroy_workqueue(vb->balloon_wq); out_del_vqs: vdev->config->del_vqs(vdev); out_free_vb: @@ -641,6 +748,11 @@ static void virtballoon_remove(struct virtio_device *vdev) cancel_work_sync(&vb->update_balloon_size_work); cancel_work_sync(&vb->update_balloon_stats_work); + if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) { + cancel_work_sync(&vb->report_free_page_work); + destroy_workqueue(vb->balloon_wq); + } + remove_common(vb); #ifdef CONFIG_BALLOON_COMPACTION if (vb->vb_dev_info.inode) @@ -692,6 +804,7 @@ static unsigned int features[] = { VIRTIO_BALLOON_F_MUST_TELL_HOST, VIRTIO_BALLOON_F_STATS_VQ, VIRTIO_BALLOON_F_DEFLATE_ON_OOM, + VIRTIO_BALLOON_F_FREE_PAGE_HINT, }; static struct virtio_driver virtio_balloon_driver = { diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h index 13b8cb5..99b8416 100644 --- a/include/uapi/linux/virtio_balloon.h +++ b/include/uapi/linux/virtio_balloon.h @@ -34,15 +34,28 @@ #define VIRTIO_BALLOON_F_MUST_TELL_HOST 0 /* Tell before reclaiming pages */ #define VIRTIO_BALLOON_F_STATS_VQ 1 /* Memory Stats virtqueue */ #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM 2 /* Deflate balloon on OOM */ +#define VIRTIO_BALLOON_F_FREE_PAGE_HINT 3 /* VQ to report free pages */ /* Size of a PFN in the balloon interface. */ #define VIRTIO_BALLOON_PFN_SHIFT 12 +#define VIRTIO_BALLOON_HOST_CMD_FREE_PAGE_HINT (1 << 0) struct virtio_balloon_config { /* Number of pages host wants Guest to give up. */ __u32 num_pages; /* Number of pages we've actually got in balloon. */ __u32 actual; + /* Command sent from host */ + __u32 host_cmd; +}; + +struct virtio_balloon_free_page_hints { + /* Number of hints in the array below */ + __le32 num_hints; + /* The size of each hint in bytes */ + __le32 size; + /* Buffer for the hints */ + __le64 buf[]; }; #define VIRTIO_BALLOON_S_SWAP_IN 0 /* Amount of memory swapped in */