search for: update_balloon_size_func

...g > was not defined when VIRTIO_BALLOON_F_DEFLATE_ON_OOM was proposed. I think the assumption is that it fill back up eventually when guest does have some free memory. > When the host increased "struct virtio_balloon_config"->num_pages and > kicked the guest, the guest's update_balloon_size_func() starts calling > fill_balloon() until "struct virtio_balloon"->num_pages reaches > "struct virtio_balloon_config"->num_pages, doesn't it? > > struct virtio_balloon_config { > /* Number of pages host wants Guest to give up. */ > __u32 num_pa...

...g > was not defined when VIRTIO_BALLOON_F_DEFLATE_ON_OOM was proposed. I think the assumption is that it fill back up eventually when guest does have some free memory. > When the host increased "struct virtio_balloon_config"->num_pages and > kicked the guest, the guest's update_balloon_size_func() starts calling > fill_balloon() until "struct virtio_balloon"->num_pages reaches > "struct virtio_balloon_config"->num_pages, doesn't it? > > struct virtio_balloon_config { > /* Number of pages host wants Guest to give up. */ > __u32 num_pa...

...ion that guest1 is started with 8192MB memory and then guest1's memory is reduced to 128MB by virsh qemu-monitor-command --domain guest1 --hmp 'balloon 128' when VIRTIO_BALLOON_F_DEFLATE_ON_OOM was not negotiated. Of course, 128MB would be too small to operate guest1 properly. Since update_balloon_size_func() continues calling fill_balloon() until guest1's memory is reduced to 128MB, you will see flooding of "puff" messages (and guest1 is practically unusable because all CPU resource will be wasted for unsuccessful memory reclaim attempts) unless the OOM killer is invoked. What this pat...

...2MB > memory and then guest1's memory is reduced to 128MB by > > virsh qemu-monitor-command --domain guest1 --hmp 'balloon 128' > > when VIRTIO_BALLOON_F_DEFLATE_ON_OOM was not negotiated. > Of course, 128MB would be too small to operate guest1 properly. > Since update_balloon_size_func() continues calling fill_balloon() > until guest1's memory is reduced to 128MB, you will see flooding of > "puff" messages (and guest1 is practically unusable because all CPU > resource will be wasted for unsuccessful memory reclaim attempts) > unless the OOM killer is inv...

...2MB > memory and then guest1's memory is reduced to 128MB by > > virsh qemu-monitor-command --domain guest1 --hmp 'balloon 128' > > when VIRTIO_BALLOON_F_DEFLATE_ON_OOM was not negotiated. > Of course, 128MB would be too small to operate guest1 properly. > Since update_balloon_size_func() continues calling fill_balloon() > until guest1's memory is reduced to 128MB, you will see flooding of > "puff" messages (and guest1 is practically unusable because all CPU > resource will be wasted for unsuccessful memory reclaim attempts) > unless the OOM killer is inv...

...irtio/virtio_balloon.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index 9a82a11..4884b85 100644 --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -435,9 +435,12 @@ static void update_balloon_size_func(struct work_struct *work) update_balloon_size_work); diff = towards_target(vb); + if (!diff) + return; + if (diff > 0) diff -= fill_balloon(vb, diff); - else if (diff < 0) + else diff += leak_balloon(vb, -diff); update_balloon_size(vb); -- 2.7.4

...1's memory is reduced to 128MB by > > > > virsh qemu-monitor-command --domain guest1 --hmp 'balloon 128' > > > > when VIRTIO_BALLOON_F_DEFLATE_ON_OOM was not negotiated. > > Of course, 128MB would be too small to operate guest1 properly. > > Since update_balloon_size_func() continues calling fill_balloon() > > until guest1's memory is reduced to 128MB, you will see flooding of > > "puff" messages (and guest1 is practically unusable because all CPU > > resource will be wasted for unsuccessful memory reclaim attempts) > > unless t...

...otifier_block *self, > return NOTIFY_OK; > > freed = parm; > - num_freed_pages = leak_balloon(vb, oom_pages); > + num_freed_pages = leak_balloon(vb, oom_pages, false); > update_balloon_size(vb); > *freed += num_freed_pages; > > @@ -395,7 +401,7 @@ static void update_balloon_size_func(struct work_struct *work) > if (diff > 0) > diff -= fill_balloon(vb, diff); > else if (diff < 0) > - diff += leak_balloon(vb, -diff); > + diff += leak_balloon(vb, -diff, true); > update_balloon_size(vb); > > if (diff) > @@ -597,7 +603,7 @@ static void...

...otifier_block *self, > return NOTIFY_OK; > > freed = parm; > - num_freed_pages = leak_balloon(vb, oom_pages); > + num_freed_pages = leak_balloon(vb, oom_pages, false); > update_balloon_size(vb); > *freed += num_freed_pages; > > @@ -395,7 +401,7 @@ static void update_balloon_size_func(struct work_struct *work) > if (diff > 0) > diff -= fill_balloon(vb, diff); > else if (diff < 0) > - diff += leak_balloon(vb, -diff); > + diff += leak_balloon(vb, -diff, true); > update_balloon_size(vb); > > if (diff) > @@ -597,7 +603,7 @@ static void...

...OOM situation. The other problem is that, although it is not complete OOM lockup, it is too slow to wait if we hit out_of_memory() => fill_balloon() => out_of_memory() => fill_balloon() sequence. > If leak_balloon() from out_of_memory() should be stronger than > fill_balloon() from update_balloon_size_func(), we need to make > sure that update_balloon_size_func() stops calling fill_balloon() > when leak_balloon() was called from out_of_memory(). I tried below patch to reduce the possibility of hitting out_of_memory() => fill_balloon() => out_of_memory() => fill_balloon() sequence. --...

...OOM situation. The other problem is that, although it is not complete OOM lockup, it is too slow to wait if we hit out_of_memory() => fill_balloon() => out_of_memory() => fill_balloon() sequence. > If leak_balloon() from out_of_memory() should be stronger than > fill_balloon() from update_balloon_size_func(), we need to make > sure that update_balloon_size_func() stops calling fill_balloon() > when leak_balloon() was called from out_of_memory(). I tried below patch to reduce the possibility of hitting out_of_memory() => fill_balloon() => out_of_memory() => fill_balloon() sequence. --...

...irtualization/2014-October/027807.html , it seems to me that the expected behavior after deflating while inflating was not defined when VIRTIO_BALLOON_F_DEFLATE_ON_OOM was proposed. When the host increased "struct virtio_balloon_config"->num_pages and kicked the guest, the guest's update_balloon_size_func() starts calling fill_balloon() until "struct virtio_balloon"->num_pages reaches "struct virtio_balloon_config"->num_pages, doesn't it? struct virtio_balloon_config { /* Number of pages host wants Guest to give up. */ __u32 num_pages; /* Number of pages we&...

...problem is that, although it is not complete OOM lockup, it is too > slow to wait if we hit out_of_memory() => fill_balloon() => out_of_memory() => > fill_balloon() sequence. > > > If leak_balloon() from out_of_memory() should be stronger than > > fill_balloon() from update_balloon_size_func(), we need to make > > sure that update_balloon_size_func() stops calling fill_balloon() > > when leak_balloon() was called from out_of_memory(). > > I tried below patch to reduce the possibility of hitting out_of_memory() => > fill_balloon() => out_of_memory() => fil...

...irtio-ccw doesn't work with accessing to the config registers inside an interrupt context, this patch series avoids that issue by moving the config register accesses to the related workqueue contexts. Wei Wang (2): virtio-balloon: tweak config_changed implementation virtio-balloon: improve update_balloon_size_func drivers/virtio/virtio_balloon.c | 59 +++++++++++++++++++++-------------------- 1 file changed, 30 insertions(+), 29 deletions(-) -- 2.7.4

...k); /* Did we get any? */ if (num_pfns != 0) @@ -173,6 +189,13 @@ static unsigned fill_balloon(struct virtio_balloon *vb, size_t num) mutex_unlock(&vb->inflate_lock); atomic64_add(num_pfns, &vb->num_pages); + /* + * If oom_mode is on, return the original @num passed by + * update_balloon_size_func to stop the inflating. + */ + if (READ_ONCE(vb->oom_mode)) + return orig_num; + return num_pfns; } @@ -365,6 +388,7 @@ static int virtballoon_oom_notify(struct notifier_block *self, if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM)) return NOTIFY_OK; + WRITE_ONC...

..._cmdq_hdr cmdq_stats_hdr; > + > + /* Cmdq msg buffer for reporting ununsed pages */ > + struct virtio_balloon_cmdq_hdr cmdq_unused_page_hdr; > + > /* To register callback in oom notifier call chain */ > struct notifier_block nb; > }; > @@ -485,25 +492,214 @@ static void update_balloon_size_func(struct work_struct *work) > queue_work(system_freezable_wq, work); > } > > +static unsigned int cmdq_hdr_add(struct virtqueue *vq, > + struct virtio_balloon_cmdq_hdr *hdr, > + bool in) > +{ > + unsigned int id = VIRTQUEUE_DESC_ID_INIT; > + uint64_t hdr_pa =...

..._cmdq_hdr cmdq_stats_hdr; > + > + /* Cmdq msg buffer for reporting ununsed pages */ > + struct virtio_balloon_cmdq_hdr cmdq_unused_page_hdr; > + > /* To register callback in oom notifier call chain */ > struct notifier_block nb; > }; > @@ -485,25 +492,214 @@ static void update_balloon_size_func(struct work_struct *work) > queue_work(system_freezable_wq, work); > } > > +static unsigned int cmdq_hdr_add(struct virtqueue *vq, > + struct virtio_balloon_cmdq_hdr *hdr, > + bool in) > +{ > + unsigned int id = VIRTQUEUE_DESC_ID_INIT; > + uint64_t hdr_pa =...

...um_pfns != 0) > @@ -173,6 +189,13 @@ static unsigned fill_balloon(struct virtio_balloon *vb, size_t num) > mutex_unlock(&vb->inflate_lock); > atomic64_add(num_pfns, &vb->num_pages); > > + /* > + * If oom_mode is on, return the original @num passed by > + * update_balloon_size_func to stop the inflating. > + */ > + if (READ_ONCE(vb->oom_mode)) > + return orig_num; > + > return num_pfns; > } > > @@ -365,6 +388,7 @@ static int virtballoon_oom_notify(struct notifier_block *self, > if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLAT...

...um_pfns != 0) > @@ -173,6 +189,13 @@ static unsigned fill_balloon(struct virtio_balloon *vb, size_t num) > mutex_unlock(&vb->inflate_lock); > atomic64_add(num_pfns, &vb->num_pages); > > + /* > + * If oom_mode is on, return the original @num passed by > + * update_balloon_size_func to stop the inflating. > + */ > + if (READ_ONCE(vb->oom_mode)) > + return orig_num; > + > return num_pfns; > } > > @@ -365,6 +388,7 @@ static int virtballoon_oom_notify(struct notifier_block *self, > if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLAT...

...s in probe since vb is allocated via kzalloc. v1->v2 ChangeLog: - add config_read_bitmap to indicate to the workqueue callbacks about the necessity of reading the related config fields. Wei Wang (3): virtio-balloon: tweak config_changed implementation virtio-balloon: improve update_balloon_size_func virtio_balloon: remove the unnecessary 0-initialization drivers/virtio/virtio_balloon.c | 104 ++++++++++++++++++++++++++-------------- 1 file changed, 69 insertions(+), 35 deletions(-) -- 2.7.4