search for: fill_balloon

On Sat, Oct 14, 2017 at 01:41:14AM +0900, Tetsuo Handa wrote: > Michael S. Tsirkin wrote: > > On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote: > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > serialize against fill_balloon(). But in fill_balloon(), > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > > > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > &gt...

On Sat, Oct 14, 2017 at 01:41:14AM +0900, Tetsuo Handa wrote: > Michael S. Tsirkin wrote: > > On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote: > > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > > serialize against fill_balloon(). But in fill_balloon(), > > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > > > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > &gt...

On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote: > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > serialize against fill_balloon(). But in fill_balloon(), > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > is specified, this allocation att...

On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote: > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > serialize against fill_balloon(). But in fill_balloon(), > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > is specified, this allocation att...

...cates pages in order to inflate the balloon, but > > > your patch will allow leak_balloon() to deflate the balloon. > > > How deflating the balloon (i.e. calling leak_balloon()) makes sense > > > when allocating pages for inflating the balloon (i.e. calling > > > fill_balloon()) ? > > > > The idea is that fill_balloon is allocating memory with __GFP_NORETRY > > so it will avoid disruptive actions like the OOM killer. > > Under pressure it will normally fail and retry in half a second or so. > > > > Calling leak_balloon in that situa...

...cates pages in order to inflate the balloon, but > > > your patch will allow leak_balloon() to deflate the balloon. > > > How deflating the balloon (i.e. calling leak_balloon()) makes sense > > > when allocating pages for inflating the balloon (i.e. calling > > > fill_balloon()) ? > > > > The idea is that fill_balloon is allocating memory with __GFP_NORETRY > > so it will avoid disruptive actions like the OOM killer. > > Under pressure it will normally fail and retry in half a second or so. > > > > Calling leak_balloon in that situa...

...> Your patch allocates pages in order to inflate the balloon, but > > your patch will allow leak_balloon() to deflate the balloon. > > How deflating the balloon (i.e. calling leak_balloon()) makes sense > > when allocating pages for inflating the balloon (i.e. calling > > fill_balloon()) ? > > The idea is that fill_balloon is allocating memory with __GFP_NORETRY > so it will avoid disruptive actions like the OOM killer. > Under pressure it will normally fail and retry in half a second or so. > > Calling leak_balloon in that situation could benefit the system...

On Fri, Dec 04, 2015 at 02:37:50PM +0100, Petr Mladek wrote: > fill_balloon() and leak_balloon() manipulate only a limited number > of pages in one call. This is the reason why remove_common() calls > leak_balloon() in a while cycle. > > remove_common() is called also when the system is being frozen. > But fill_balloon() is called only once when the system...

On Fri, Dec 04, 2015 at 02:37:50PM +0100, Petr Mladek wrote: > fill_balloon() and leak_balloon() manipulate only a limited number > of pages in one call. This is the reason why remove_common() calls > leak_balloon() in a while cycle. > > remove_common() is called also when the system is being frozen. > But fill_balloon() is called only once when the system...

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn> Add the missing unlock before return from function fill_balloon() in the error handling case. Introduced by 9864a8(virtio_balloon: introduce migration primitives to balloon pages) dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn> --- drivers/virtio/virtio_...

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn> Add the missing unlock before return from function fill_balloon() in the error handling case. Introduced by 9864a8(virtio_balloon: introduce migration primitives to balloon pages) dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn> --- drivers/virtio/virtio_...

...to inflate the balloon, but > > > > your patch will allow leak_balloon() to deflate the balloon. > > > > How deflating the balloon (i.e. calling leak_balloon()) makes sense > > > > when allocating pages for inflating the balloon (i.e. calling > > > > fill_balloon()) ? > > > > > > The idea is that fill_balloon is allocating memory with __GFP_NORETRY > > > so it will avoid disruptive actions like the OOM killer. > > > Under pressure it will normally fail and retry in half a second or so. > > > > > > Call...

Michael S. Tsirkin wrote: > On Tue, Oct 10, 2017 at 07:47:37PM +0900, Tetsuo Handa wrote: > > In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to > > serialize against fill_balloon(). But in fill_balloon(), > > alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is > > called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] > > implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, despite __GFP_NORETRY > > is specified,...

Hello. I noticed that virtio_balloon is using register_oom_notifier() and leak_balloon() from virtballoon_oom_notify() might depend on __GFP_DIRECT_RECLAIM memory allocation. In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might depend on somebody else's __GFP_DIRECT_RE...

Hello. I noticed that virtio_balloon is using register_oom_notifier() and leak_balloon() from virtballoon_oom_notify() might depend on __GFP_DIRECT_RECLAIM memory allocation. In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize against fill_balloon(). But in fill_balloon(), alloc_page(GFP_HIGHUSER[_MOVABLE] | __GFP_NOMEMALLOC | __GFP_NORETRY) is called with vb->balloon_lock mutex held. Since GFP_HIGHUSER[_MOVABLE] implies __GFP_DIRECT_RECLAIM | __GFP_IO | __GFP_FS, this allocation attempt might depend on somebody else's __GFP_DIRECT_RE...

Tetsuo Handa wrote: > 20171016-deflate.log.xz continued printing "puff" messages without any OOM > killer messages, for fill_balloon() always inflates faster than leak_balloon() > deflates. > > Since the OOM killer cannot be invoked unless leak_balloon() completely > deflates faster than fill_balloon() inflates, the guest remained unusable > (e.g. unable to login via ssh) other than printing "puff" mess...

Tetsuo Handa wrote: > 20171016-deflate.log.xz continued printing "puff" messages without any OOM > killer messages, for fill_balloon() always inflates faster than leak_balloon() > deflates. > > Since the OOM killer cannot be invoked unless leak_balloon() completely > deflates faster than fill_balloon() inflates, the guest remained unusable > (e.g. unable to login via ssh) other than printing "puff" mess...

We recently added locking in fill_balloon() but there was one error path which was missed. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Only needed in linux-next. diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index f70151b..1c50e98 100644 --- a/drivers/virtio/virtio_balloon.c +++ b...

We recently added locking in fill_balloon() but there was one error path which was missed. Signed-off-by: Dan Carpenter <dan.carpenter at oracle.com> --- Only needed in linux-next. diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index f70151b..1c50e98 100644 --- a/drivers/virtio/virtio_balloon.c +++ b...

...outcome. I have added one more patch that fixes a separate problem with restoring the balloon after the system freeze. I have found this when testing the conversion. Changes against v3: + rebased on 4.4-rc3 + call cancel_work_synch() when removing the balloon + do not queue the work from fill_balloon() and leak_balloon() because they are called also independently from the workqueue, e.g. remove_common(), virtballoon_oom_notify(). Re-queue the work from the work function when necessary. Changes against v2: + Use system_freezable_wq instead of an allocated one and move INIT_W...