| Message ID | 1532683495-31974-3-git-send-email-wei.w.wang@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | virtio-balloon: some improvements | expand |
On Fri 27-07-18 17:24:55, Wei Wang wrote: > The OOM notifier is getting deprecated to use for the reasons mentioned > here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314 > > This patch replaces the virtio-balloon oom notifier with a shrinker > to release balloon pages on memory pressure. It would be great to document the replacement. This is not a small change... > In addition, the bug in the replaced virtballoon_oom_notify that only > VIRTIO_BALLOON_ARRAY_PFNS_MAX (i.e 256) balloon pages can be freed > though the user has specified more than that number is fixed in the > shrinker_scan function. > > Signed-off-by: Wei Wang <wei.w.wang@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 | 115 +++++++++++++++++++++++----------------- > 1 file changed, 65 insertions(+), 50 deletions(-) > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c > index 9356a1a..6b2229b 100644 > --- a/drivers/virtio/virtio_balloon.c > +++ b/drivers/virtio/virtio_balloon.c > @@ -27,7 +27,6 @@ > #include <linux/slab.h> > #include <linux/module.h> > #include <linux/balloon_compaction.h> > -#include <linux/oom.h> > #include <linux/wait.h> > #include <linux/mm.h> > #include <linux/mount.h> > @@ -40,12 +39,12 @@ > */ > #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT) > #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256 > -#define OOM_VBALLOON_DEFAULT_PAGES 256 > +#define DEFAULT_BALLOON_PAGES_TO_SHRINK 256 > #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80 > > -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"); > +static unsigned long balloon_pages_to_shrink = DEFAULT_BALLOON_PAGES_TO_SHRINK; > +module_param(balloon_pages_to_shrink, ulong, 0600); > +MODULE_PARM_DESC(balloon_pages_to_shrink, "pages to free on memory presure"); > > #ifdef CONFIG_BALLOON_COMPACTION > static struct vfsmount *balloon_mnt; > @@ -86,8 +85,8 @@ struct virtio_balloon { > /* Memory statistics */ > struct virtio_balloon_stat stats[VIRTIO_BALLOON_S_NR]; > > - /* To register callback in oom notifier call chain */ > - struct notifier_block nb; > + /* To register a shrinker to shrink memory upon memory pressure */ > + struct shrinker shrinker; > }; > > static struct virtio_device_id id_table[] = { > @@ -365,38 +364,6 @@ static void update_balloon_size(struct virtio_balloon *vb) > &actual); > } > > -/* > - * virtballoon_oom_notify - release pages when system is under severe > - * memory pressure (called from out_of_memory()) > - * @self : notifier block struct > - * @dummy: not used > - * @parm : returned - number of freed pages > - * > - * The balancing of memory by use of the virtio balloon should not cause > - * the termination of processes while there are pages in the balloon. > - * If virtio balloon manages to release some memory, it will make the > - * system return and retry the allocation that forced the OOM killer > - * to run. > - */ > -static int virtballoon_oom_notify(struct notifier_block *self, > - unsigned long dummy, void *parm) > -{ > - struct virtio_balloon *vb; > - unsigned long *freed; > - unsigned num_freed_pages; > - > - vb = container_of(self, struct virtio_balloon, nb); > - if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM)) > - return NOTIFY_OK; > - > - freed = parm; > - num_freed_pages = leak_balloon(vb, oom_pages); > - update_balloon_size(vb); > - *freed += num_freed_pages; > - > - return NOTIFY_OK; > -} > - > static void update_balloon_stats_func(struct work_struct *work) > { > struct virtio_balloon *vb; > @@ -548,6 +515,54 @@ static struct file_system_type balloon_fs = { > > #endif /* CONFIG_BALLOON_COMPACTION */ > > +static unsigned long virtio_balloon_shrinker_scan(struct shrinker *shrinker, > + struct shrink_control *sc) > +{ > + unsigned long pages_to_free = balloon_pages_to_shrink, > + pages_freed = 0; > + struct virtio_balloon *vb = container_of(shrinker, > + struct virtio_balloon, shrinker); > + > + /* > + * One invocation of leak_balloon can deflate at most > + * VIRTIO_BALLOON_ARRAY_PFNS_MAX balloon pages, so we call it > + * multiple times to deflate pages till reaching > + * balloon_pages_to_shrink pages. > + */ > + while (vb->num_pages && pages_to_free) { > + pages_to_free = balloon_pages_to_shrink - pages_freed; > + pages_freed += leak_balloon(vb, pages_to_free); > + } > + update_balloon_size(vb); > + > + return pages_freed / VIRTIO_BALLOON_PAGES_PER_PAGE; > +} > + > +static unsigned long virtio_balloon_shrinker_count(struct shrinker *shrinker, > + struct shrink_control *sc) > +{ > + struct virtio_balloon *vb = container_of(shrinker, > + struct virtio_balloon, shrinker); > + > + return min_t(unsigned long, vb->num_pages, balloon_pages_to_shrink) / > + VIRTIO_BALLOON_PAGES_PER_PAGE; > +} > + > +static void virtio_balloon_unregister_shrinker(struct virtio_balloon *vb) > +{ > + unregister_shrinker(&vb->shrinker); > +} > + > +static int virtio_balloon_register_shrinker(struct virtio_balloon *vb) > +{ > + vb->shrinker.scan_objects = virtio_balloon_shrinker_scan; > + vb->shrinker.count_objects = virtio_balloon_shrinker_count; > + vb->shrinker.batch = 0; > + vb->shrinker.seeks = DEFAULT_SEEKS; > + > + return register_shrinker(&vb->shrinker); > +} > + > static int virtballoon_probe(struct virtio_device *vdev) > { > struct virtio_balloon *vb; > @@ -580,17 +595,10 @@ static int virtballoon_probe(struct virtio_device *vdev) > if (err) > goto out_free_vb; > > - 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; > - > #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; > } > > @@ -599,13 +607,20 @@ static int virtballoon_probe(struct virtio_device *vdev) > if (IS_ERR(vb->vb_dev_info.inode)) { > err = PTR_ERR(vb->vb_dev_info.inode); > kern_unmount(balloon_mnt); > - unregister_oom_notifier(&vb->nb); > vb->vb_dev_info.inode = NULL; > goto out_del_vqs; > } > vb->vb_dev_info.inode->i_mapping->a_ops = &balloon_aops; > #endif > - > + /* > + * We continue to use VIRTIO_BALLOON_F_DEFLATE_ON_OOM to decide if a > + * shrinker needs to be registered to relieve memory pressure. > + */ > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM)) { > + err = virtio_balloon_register_shrinker(vb); > + if (err) > + goto out_del_vqs; > + } > virtio_device_ready(vdev); > > if (towards_target(vb)) > @@ -637,8 +652,8 @@ static void virtballoon_remove(struct virtio_device *vdev) > { > struct virtio_balloon *vb = vdev->priv; > > - unregister_oom_notifier(&vb->nb); > - > + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM)) > + virtio_balloon_unregister_shrinker(vb); > spin_lock_irq(&vb->stop_update_lock); > vb->stop_update = true; > spin_unlock_irq(&vb->stop_update_lock); > -- > 2.7.4
On 07/30/2018 05:00 PM, Michal Hocko wrote: > On Fri 27-07-18 17:24:55, Wei Wang wrote: >> The OOM notifier is getting deprecated to use for the reasons mentioned >> here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314 >> >> This patch replaces the virtio-balloon oom notifier with a shrinker >> to release balloon pages on memory pressure. > It would be great to document the replacement. This is not a small > change... OK. I plan to document the following to the commit log: The OOM notifier is getting deprecated to use for the reasons: - As a callout from the oom context, it is too subtle and easy to generate bugs and corner cases which are hard to track; - It is called too late (after the reclaiming has been performed). Drivers with large amuont of reclaimable memory is expected to be released them at an early age of memory pressure; - The notifier callback isn't aware of the oom contrains; Link: https://lkml.org/lkml/2018/7/12/314 This patch replaces the virtio-balloon oom notifier with a shrinker to release balloon pages on memory pressure. Users can set the amount of memory pages to release each time a shrinker_scan is called via the module parameter balloon_pages_to_shrink, and the default amount is 256 pages. Historically, the feature VIRTIO_BALLOON_F_DEFLATE_ON_OOM has been used to release balloon pages on OOM. We continue to use this feature bit for the shrinker, so the shrinker is only registered when this feature bit has been negotiated with host. In addition, the bug in the replaced virtballoon_oom_notify that only VIRTIO_BALLOON_ARRAY_PFNS_MAX (i.e 256) balloon pages can be freed though the user has specified more than that number is fixed in the shrinker_scan function. Best, Wei
On Wed 01-08-18 19:12:25, Wei Wang wrote: > On 07/30/2018 05:00 PM, Michal Hocko wrote: > > On Fri 27-07-18 17:24:55, Wei Wang wrote: > > > The OOM notifier is getting deprecated to use for the reasons mentioned > > > here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314 > > > > > > This patch replaces the virtio-balloon oom notifier with a shrinker > > > to release balloon pages on memory pressure. > > It would be great to document the replacement. This is not a small > > change... > > OK. I plan to document the following to the commit log: > > The OOM notifier is getting deprecated to use for the reasons: > - As a callout from the oom context, it is too subtle and easy to > generate bugs and corner cases which are hard to track; > - It is called too late (after the reclaiming has been performed). > Drivers with large amuont of reclaimable memory is expected to be > released them at an early age of memory pressure; > - The notifier callback isn't aware of the oom contrains; > Link: https://lkml.org/lkml/2018/7/12/314 > > This patch replaces the virtio-balloon oom notifier with a shrinker > to release balloon pages on memory pressure. Users can set the amount of > memory pages to release each time a shrinker_scan is called via the > module parameter balloon_pages_to_shrink, and the default amount is 256 > pages. Historically, the feature VIRTIO_BALLOON_F_DEFLATE_ON_OOM has > been used to release balloon pages on OOM. We continue to use this > feature bit for the shrinker, so the shrinker is only registered when > this feature bit has been negotiated with host. Do you have any numbers for how does this work in practice? Let's say you have a medium page cache workload which triggers kswapd to do a light reclaim? Hardcoded shrinking sounds quite dubious to me but I have no idea how people expect this to work. Shouldn't this be more adaptive? How precious are those pages anyway?
On 08/01/2018 07:34 PM, Michal Hocko wrote: > On Wed 01-08-18 19:12:25, Wei Wang wrote: >> On 07/30/2018 05:00 PM, Michal Hocko wrote: >>> On Fri 27-07-18 17:24:55, Wei Wang wrote: >>>> The OOM notifier is getting deprecated to use for the reasons mentioned >>>> here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314 >>>> >>>> This patch replaces the virtio-balloon oom notifier with a shrinker >>>> to release balloon pages on memory pressure. >>> It would be great to document the replacement. This is not a small >>> change... >> OK. I plan to document the following to the commit log: >> >> The OOM notifier is getting deprecated to use for the reasons: >> - As a callout from the oom context, it is too subtle and easy to >> generate bugs and corner cases which are hard to track; >> - It is called too late (after the reclaiming has been performed). >> Drivers with large amuont of reclaimable memory is expected to be >> released them at an early age of memory pressure; >> - The notifier callback isn't aware of the oom contrains; >> Link: https://lkml.org/lkml/2018/7/12/314 >> >> This patch replaces the virtio-balloon oom notifier with a shrinker >> to release balloon pages on memory pressure. Users can set the amount of >> memory pages to release each time a shrinker_scan is called via the >> module parameter balloon_pages_to_shrink, and the default amount is 256 >> pages. Historically, the feature VIRTIO_BALLOON_F_DEFLATE_ON_OOM has >> been used to release balloon pages on OOM. We continue to use this >> feature bit for the shrinker, so the shrinker is only registered when >> this feature bit has been negotiated with host. > Do you have any numbers for how does this work in practice? It works in this way: for example, we can set the parameter, balloon_pages_to_shrink, to shrink 1GB memory once shrink scan is called. Now, we have a 8GB guest, and we balloon out 7GB. When shrink scan is called, the balloon driver will get back 1GB memory and give them back to mm, then the ballooned memory becomes 6GB. When the shrinker scan is called the second time, another 1GB will be given back to mm. So the ballooned pages are given back to mm gradually. > Let's say > you have a medium page cache workload which triggers kswapd to do a > light reclaim? Hardcoded shrinking sounds quite dubious to me but I have > no idea how people expect this to work. Shouldn't this be more > adaptive? How precious are those pages anyway? Those pages are given to host to use usually because the guest has enough free memory, and host doesn't want to waste those pieces of memory as they are not used by this guest. When the guest needs them, it is reasonable that the guest has higher priority to take them back. But I'm not sure if there would be a more adaptive approach than "gradually giving back as the guest wants more". Best, Wei
On 2018/08/02 19:32, Wei Wang wrote: > On 08/01/2018 07:34 PM, Michal Hocko wrote: >> Do you have any numbers for how does this work in practice? > > It works in this way: for example, we can set the parameter, balloon_pages_to_shrink, > to shrink 1GB memory once shrink scan is called. Now, we have a 8GB guest, and we balloon > out 7GB. When shrink scan is called, the balloon driver will get back 1GB memory and give > them back to mm, then the ballooned memory becomes 6GB. Since shrinker might be called concurrently (am I correct?), the balloon might deflate far more than needed if it releases such much memory. If shrinker is used, releasing 256 pages might be sufficient.
On 08/02/2018 07:00 PM, Tetsuo Handa wrote: > On 2018/08/02 19:32, Wei Wang wrote: >> On 08/01/2018 07:34 PM, Michal Hocko wrote: >>> Do you have any numbers for how does this work in practice? >> It works in this way: for example, we can set the parameter, balloon_pages_to_shrink, >> to shrink 1GB memory once shrink scan is called. Now, we have a 8GB guest, and we balloon >> out 7GB. When shrink scan is called, the balloon driver will get back 1GB memory and give >> them back to mm, then the ballooned memory becomes 6GB. > Since shrinker might be called concurrently (am I correct?), Not sure about it being concurrently, but I think it would be called repeatedly as should_continue_reclaim() returns true. Best, Wei
On Thu 02-08-18 19:27:40, Wei Wang wrote: > On 08/02/2018 07:00 PM, Tetsuo Handa wrote: > > On 2018/08/02 19:32, Wei Wang wrote: > > > On 08/01/2018 07:34 PM, Michal Hocko wrote: > > > > Do you have any numbers for how does this work in practice? > > > It works in this way: for example, we can set the parameter, balloon_pages_to_shrink, > > > to shrink 1GB memory once shrink scan is called. Now, we have a 8GB guest, and we balloon > > > out 7GB. When shrink scan is called, the balloon driver will get back 1GB memory and give > > > them back to mm, then the ballooned memory becomes 6GB. > > Since shrinker might be called concurrently (am I correct?), > > Not sure about it being concurrently, but I think it would be called > repeatedly as should_continue_reclaim() returns true. Multiple direct reclaimers might indeed invoke it concurrently.
On Thu 02-08-18 18:32:44, Wei Wang wrote: > On 08/01/2018 07:34 PM, Michal Hocko wrote: > > On Wed 01-08-18 19:12:25, Wei Wang wrote: > > > On 07/30/2018 05:00 PM, Michal Hocko wrote: > > > > On Fri 27-07-18 17:24:55, Wei Wang wrote: > > > > > The OOM notifier is getting deprecated to use for the reasons mentioned > > > > > here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314 > > > > > > > > > > This patch replaces the virtio-balloon oom notifier with a shrinker > > > > > to release balloon pages on memory pressure. > > > > It would be great to document the replacement. This is not a small > > > > change... > > > OK. I plan to document the following to the commit log: > > > > > > The OOM notifier is getting deprecated to use for the reasons: > > > - As a callout from the oom context, it is too subtle and easy to > > > generate bugs and corner cases which are hard to track; > > > - It is called too late (after the reclaiming has been performed). > > > Drivers with large amuont of reclaimable memory is expected to be > > > released them at an early age of memory pressure; > > > - The notifier callback isn't aware of the oom contrains; > > > Link: https://lkml.org/lkml/2018/7/12/314 > > > > > > This patch replaces the virtio-balloon oom notifier with a shrinker > > > to release balloon pages on memory pressure. Users can set the amount of > > > memory pages to release each time a shrinker_scan is called via the > > > module parameter balloon_pages_to_shrink, and the default amount is 256 > > > pages. Historically, the feature VIRTIO_BALLOON_F_DEFLATE_ON_OOM has > > > been used to release balloon pages on OOM. We continue to use this > > > feature bit for the shrinker, so the shrinker is only registered when > > > this feature bit has been negotiated with host. > > Do you have any numbers for how does this work in practice? > > It works in this way: for example, we can set the parameter, > balloon_pages_to_shrink, to shrink 1GB memory once shrink scan is called. > Now, we have a 8GB guest, and we balloon out 7GB. When shrink scan is > called, the balloon driver will get back 1GB memory and give them back to > mm, then the ballooned memory becomes 6GB. > > When the shrinker scan is called the second time, another 1GB will be given > back to mm. So the ballooned pages are given back to mm gradually. > > > Let's say > > you have a medium page cache workload which triggers kswapd to do a > > light reclaim? Hardcoded shrinking sounds quite dubious to me but I have > > no idea how people expect this to work. Shouldn't this be more > > adaptive? How precious are those pages anyway? > > Those pages are given to host to use usually because the guest has enough > free memory, and host doesn't want to waste those pieces of memory as they > are not used by this guest. When the guest needs them, it is reasonable that > the guest has higher priority to take them back. > But I'm not sure if there would be a more adaptive approach than "gradually > giving back as the guest wants more". I am not sure I follow. Let me be more specific. Say you have a trivial stream IO triggering reclaim to recycle clean page cache. This will invoke slab shrinkers as well. Do you really want to drop your batch of pages on each invocation? Doesn't that remove them very quickly? Just try to dd if=large_file of=/dev/null and see how your pages are disappearing. Shrinkers usually scale the number of objects they are going to reclaim based on the memory pressure (aka targer to be reclaimed).
On Thu, Aug 02, 2018 at 06:32:44PM +0800, Wei Wang wrote: > On 08/01/2018 07:34 PM, Michal Hocko wrote: > > On Wed 01-08-18 19:12:25, Wei Wang wrote: > > > On 07/30/2018 05:00 PM, Michal Hocko wrote: > > > > On Fri 27-07-18 17:24:55, Wei Wang wrote: > > > > > The OOM notifier is getting deprecated to use for the reasons mentioned > > > > > here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314 > > > > > > > > > > This patch replaces the virtio-balloon oom notifier with a shrinker > > > > > to release balloon pages on memory pressure. > > > > It would be great to document the replacement. This is not a small > > > > change... > > > OK. I plan to document the following to the commit log: > > > > > > The OOM notifier is getting deprecated to use for the reasons: > > > - As a callout from the oom context, it is too subtle and easy to > > > generate bugs and corner cases which are hard to track; > > > - It is called too late (after the reclaiming has been performed). > > > Drivers with large amuont of reclaimable memory is expected to be > > > released them at an early age of memory pressure; > > > - The notifier callback isn't aware of the oom contrains; > > > Link: https://lkml.org/lkml/2018/7/12/314 > > > > > > This patch replaces the virtio-balloon oom notifier with a shrinker > > > to release balloon pages on memory pressure. Users can set the amount of > > > memory pages to release each time a shrinker_scan is called via the > > > module parameter balloon_pages_to_shrink, and the default amount is 256 > > > pages. Historically, the feature VIRTIO_BALLOON_F_DEFLATE_ON_OOM has > > > been used to release balloon pages on OOM. We continue to use this > > > feature bit for the shrinker, so the shrinker is only registered when > > > this feature bit has been negotiated with host. > > Do you have any numbers for how does this work in practice? > > It works in this way: for example, we can set the parameter, > balloon_pages_to_shrink, to shrink 1GB memory once shrink scan is called. > Now, we have a 8GB guest, and we balloon out 7GB. When shrink scan is > called, the balloon driver will get back 1GB memory and give them back to > mm, then the ballooned memory becomes 6GB. > > When the shrinker scan is called the second time, another 1GB will be given > back to mm. So the ballooned pages are given back to mm gradually. I think what's being asked here is a description of tests that were run. Which workloads see improved behaviour? Our behaviour under memory pressure isn't great, in particular it is not clear when it's safe to re-inflate the balloon, if host attempts to re-inflate it too soon then we still get OOM. It would be better if VIRTIO_BALLOON_F_DEFLATE_ON_OOM would somehow mean "it's ok to ask for almost all of memory, if guest needs memory from balloon for apps to function it can take it from the balloon".
On 08/02/2018 07:47 PM, Michal Hocko wrote: > On Thu 02-08-18 18:32:44, Wei Wang wrote: >> On 08/01/2018 07:34 PM, Michal Hocko wrote: >>> On Wed 01-08-18 19:12:25, Wei Wang wrote: >>>> On 07/30/2018 05:00 PM, Michal Hocko wrote: >>>>> On Fri 27-07-18 17:24:55, Wei Wang wrote: >>>>>> The OOM notifier is getting deprecated to use for the reasons mentioned >>>>>> here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314 >>>>>> >>>>>> This patch replaces the virtio-balloon oom notifier with a shrinker >>>>>> to release balloon pages on memory pressure. >>>>> It would be great to document the replacement. This is not a small >>>>> change... >>>> OK. I plan to document the following to the commit log: >>>> >>>> The OOM notifier is getting deprecated to use for the reasons: >>>> - As a callout from the oom context, it is too subtle and easy to >>>> generate bugs and corner cases which are hard to track; >>>> - It is called too late (after the reclaiming has been performed). >>>> Drivers with large amuont of reclaimable memory is expected to be >>>> released them at an early age of memory pressure; >>>> - The notifier callback isn't aware of the oom contrains; >>>> Link: https://lkml.org/lkml/2018/7/12/314 >>>> >>>> This patch replaces the virtio-balloon oom notifier with a shrinker >>>> to release balloon pages on memory pressure. Users can set the amount of >>>> memory pages to release each time a shrinker_scan is called via the >>>> module parameter balloon_pages_to_shrink, and the default amount is 256 >>>> pages. Historically, the feature VIRTIO_BALLOON_F_DEFLATE_ON_OOM has >>>> been used to release balloon pages on OOM. We continue to use this >>>> feature bit for the shrinker, so the shrinker is only registered when >>>> this feature bit has been negotiated with host. >>> Do you have any numbers for how does this work in practice? >> It works in this way: for example, we can set the parameter, >> balloon_pages_to_shrink, to shrink 1GB memory once shrink scan is called. >> Now, we have a 8GB guest, and we balloon out 7GB. When shrink scan is >> called, the balloon driver will get back 1GB memory and give them back to >> mm, then the ballooned memory becomes 6GB. >> >> When the shrinker scan is called the second time, another 1GB will be given >> back to mm. So the ballooned pages are given back to mm gradually. >> >>> Let's say >>> you have a medium page cache workload which triggers kswapd to do a >>> light reclaim? Hardcoded shrinking sounds quite dubious to me but I have >>> no idea how people expect this to work. Shouldn't this be more >>> adaptive? How precious are those pages anyway? >> Those pages are given to host to use usually because the guest has enough >> free memory, and host doesn't want to waste those pieces of memory as they >> are not used by this guest. When the guest needs them, it is reasonable that >> the guest has higher priority to take them back. >> But I'm not sure if there would be a more adaptive approach than "gradually >> giving back as the guest wants more". > I am not sure I follow. Let me be more specific. Say you have a trivial > stream IO triggering reclaim to recycle clean page cache. This will > invoke slab shrinkers as well. Do you really want to drop your batch of > pages on each invocation? Doesn't that remove them very quickly? Just > try to dd if=large_file of=/dev/null and see how your pages are > disappearing. Shrinkers usually scale the number of objects they are > going to reclaim based on the memory pressure (aka targer to be > reclaimed). Thanks, I think it looks better to make it more adaptive. I'll send out a new version for review. Best, Wei
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index 9356a1a..6b2229b 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -27,7 +27,6 @@ #include <linux/slab.h> #include <linux/module.h> #include <linux/balloon_compaction.h> -#include <linux/oom.h> #include <linux/wait.h> #include <linux/mm.h> #include <linux/mount.h> @@ -40,12 +39,12 @@ */ #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT) #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256 -#define OOM_VBALLOON_DEFAULT_PAGES 256 +#define DEFAULT_BALLOON_PAGES_TO_SHRINK 256 #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80 -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"); +static unsigned long balloon_pages_to_shrink = DEFAULT_BALLOON_PAGES_TO_SHRINK; +module_param(balloon_pages_to_shrink, ulong, 0600); +MODULE_PARM_DESC(balloon_pages_to_shrink, "pages to free on memory presure"); #ifdef CONFIG_BALLOON_COMPACTION static struct vfsmount *balloon_mnt; @@ -86,8 +85,8 @@ struct virtio_balloon { /* Memory statistics */ struct virtio_balloon_stat stats[VIRTIO_BALLOON_S_NR]; - /* To register callback in oom notifier call chain */ - struct notifier_block nb; + /* To register a shrinker to shrink memory upon memory pressure */ + struct shrinker shrinker; }; static struct virtio_device_id id_table[] = { @@ -365,38 +364,6 @@ static void update_balloon_size(struct virtio_balloon *vb) &actual); } -/* - * virtballoon_oom_notify - release pages when system is under severe - * memory pressure (called from out_of_memory()) - * @self : notifier block struct - * @dummy: not used - * @parm : returned - number of freed pages - * - * The balancing of memory by use of the virtio balloon should not cause - * the termination of processes while there are pages in the balloon. - * If virtio balloon manages to release some memory, it will make the - * system return and retry the allocation that forced the OOM killer - * to run. - */ -static int virtballoon_oom_notify(struct notifier_block *self, - unsigned long dummy, void *parm) -{ - struct virtio_balloon *vb; - unsigned long *freed; - unsigned num_freed_pages; - - vb = container_of(self, struct virtio_balloon, nb); - if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM)) - return NOTIFY_OK; - - freed = parm; - num_freed_pages = leak_balloon(vb, oom_pages); - update_balloon_size(vb); - *freed += num_freed_pages; - - return NOTIFY_OK; -} - static void update_balloon_stats_func(struct work_struct *work) { struct virtio_balloon *vb; @@ -548,6 +515,54 @@ static struct file_system_type balloon_fs = { #endif /* CONFIG_BALLOON_COMPACTION */ +static unsigned long virtio_balloon_shrinker_scan(struct shrinker *shrinker, + struct shrink_control *sc) +{ + unsigned long pages_to_free = balloon_pages_to_shrink, + pages_freed = 0; + struct virtio_balloon *vb = container_of(shrinker, + struct virtio_balloon, shrinker); + + /* + * One invocation of leak_balloon can deflate at most + * VIRTIO_BALLOON_ARRAY_PFNS_MAX balloon pages, so we call it + * multiple times to deflate pages till reaching + * balloon_pages_to_shrink pages. + */ + while (vb->num_pages && pages_to_free) { + pages_to_free = balloon_pages_to_shrink - pages_freed; + pages_freed += leak_balloon(vb, pages_to_free); + } + update_balloon_size(vb); + + return pages_freed / VIRTIO_BALLOON_PAGES_PER_PAGE; +} + +static unsigned long virtio_balloon_shrinker_count(struct shrinker *shrinker, + struct shrink_control *sc) +{ + struct virtio_balloon *vb = container_of(shrinker, + struct virtio_balloon, shrinker); + + return min_t(unsigned long, vb->num_pages, balloon_pages_to_shrink) / + VIRTIO_BALLOON_PAGES_PER_PAGE; +} + +static void virtio_balloon_unregister_shrinker(struct virtio_balloon *vb) +{ + unregister_shrinker(&vb->shrinker); +} + +static int virtio_balloon_register_shrinker(struct virtio_balloon *vb) +{ + vb->shrinker.scan_objects = virtio_balloon_shrinker_scan; + vb->shrinker.count_objects = virtio_balloon_shrinker_count; + vb->shrinker.batch = 0; + vb->shrinker.seeks = DEFAULT_SEEKS; + + return register_shrinker(&vb->shrinker); +} + static int virtballoon_probe(struct virtio_device *vdev) { struct virtio_balloon *vb; @@ -580,17 +595,10 @@ static int virtballoon_probe(struct virtio_device *vdev) if (err) goto out_free_vb; - 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; - #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; } @@ -599,13 +607,20 @@ static int virtballoon_probe(struct virtio_device *vdev) if (IS_ERR(vb->vb_dev_info.inode)) { err = PTR_ERR(vb->vb_dev_info.inode); kern_unmount(balloon_mnt); - unregister_oom_notifier(&vb->nb); vb->vb_dev_info.inode = NULL; goto out_del_vqs; } vb->vb_dev_info.inode->i_mapping->a_ops = &balloon_aops; #endif - + /* + * We continue to use VIRTIO_BALLOON_F_DEFLATE_ON_OOM to decide if a + * shrinker needs to be registered to relieve memory pressure. + */ + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM)) { + err = virtio_balloon_register_shrinker(vb); + if (err) + goto out_del_vqs; + } virtio_device_ready(vdev); if (towards_target(vb)) @@ -637,8 +652,8 @@ static void virtballoon_remove(struct virtio_device *vdev) { struct virtio_balloon *vb = vdev->priv; - unregister_oom_notifier(&vb->nb); - + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM)) + virtio_balloon_unregister_shrinker(vb); spin_lock_irq(&vb->stop_update_lock); vb->stop_update = true; spin_unlock_irq(&vb->stop_update_lock);
The OOM notifier is getting deprecated to use for the reasons mentioned here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314 This patch replaces the virtio-balloon oom notifier with a shrinker to release balloon pages on memory pressure. In addition, the bug in the replaced virtballoon_oom_notify that only VIRTIO_BALLOON_ARRAY_PFNS_MAX (i.e 256) balloon pages can be freed though the user has specified more than that number is fixed in the shrinker_scan function. Signed-off-by: Wei Wang <wei.w.wang@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 | 115 +++++++++++++++++++++++----------------- 1 file changed, 65 insertions(+), 50 deletions(-)