On Tue, Jan 05, 2016 at 03:37:33PM +0100, Petr Mladek wrote: > On Fri 2016-01-01 12:13:48, Michael S. Tsirkin wrote: > > Peter Mladek reported that balloon might never refill completely after > > restore. This is because fill_balloon is only called once there. > > Calling fill_balloon repeatedly seems too aggressive, > > especially in light of the fact that it sleeps on failure: let's > > wake the config change handler and fill it asynchronously. > > > > Reported-by: Petr Mladek <pmla...@suse.com> > > Signed-off-by: Michael S. Tsirkin <m...@redhat.com> > > --- > > > > I was unable to test this - for some reason my test VM > > doesn't resume (with or without the patch). > > Petr, does this work for you? > > Ah, I have just realized that the problem happens only after the > conversion to the workqueue. It works without this patch with the > current code. The balloon kthread is waken when released from > __refrigerator().
In fact, maybe we should drop fill_balloon and update_balloon_size here? Resume will finish faster ... > I am sorry for the noise. I wanted to split the conversion to > workqueues into two patches to make it better readable. We need to > queue the balloon resizing work here. I wrongly assumed that the > original kthread must have the same problem. > > Best Regards, > Petr > > > drivers/virtio/virtio_balloon.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/virtio/virtio_balloon.c > > b/drivers/virtio/virtio_balloon.c > > index 7efc329..ee29473 100644 > > --- a/drivers/virtio/virtio_balloon.c > > +++ b/drivers/virtio/virtio_balloon.c > > @@ -589,7 +589,7 @@ static int virtballoon_restore(struct virtio_device > > *vdev) > > > > virtio_device_ready(vdev); > > > > - fill_balloon(vb, towards_target(vb)); > > + wake_up(&vb->config_change); > > update_balloon_size(vb); > > return 0; > > } > > -- > > MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/