similar to: [PATCH RFC] virtio_balloon: refill by config handler

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.

It has been long since I have sent v3 of the balloon conversion from a kthread to a workqueue. I have gained some more experience with the APIs in the meantime. I hope that you would like the 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

It has been long since I have sent v3 of the balloon conversion from a kthread to a workqueue. I have gained some more experience with the APIs in the meantime. I hope that you would like the 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

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 is being >

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 is being >

The previous version did not prevent updating the balloon when it was being removed. There was an idea to update the stats in a separate work and cancel it after the config reset. But this does not seem to work. The code for updating the stats communicates with the host. IMHO, it should not run after the reset (flushing buffers). Therefore I decided to use a boolean value and a spin lock (inspired

The previous version did not prevent updating the balloon when it was being removed. There was an idea to update the stats in a separate work and cancel it after the config reset. But this does not seem to work. The code for updating the stats communicates with the host. IMHO, it should not run after the reset (flushing buffers). Therefore I decided to use a boolean value and a spin lock (inspired

Workqueues have clean and rich API for all basic operations. The code is usually easier and better readable. It can be easily tuned for the given purpose. In many cases, it allows to avoid an extra kernel thread. It helps to stop the growing number of them. Also there will be less thread-specific hacks all over the kernel code. It forces making the task selfcontained. There is no longer an

Workqueues have clean and rich API for all basic operations. The code is usually easier and better readable. It can be easily tuned for the given purpose. In many cases, it allows to avoid an extra kernel thread. It helps to stop the growing number of them. Also there will be less thread-specific hacks all over the kernel code. It forces making the task selfcontained. There is no longer an

Workqueues have clean and rich API for all basic operations. The code is usually easier and better readable. It can be easily tuned for the given purpose. In many cases, it allows to avoid an extra kernel thread. It helps to stop the growing number of them. Also there will be less thread-specific hacks all over the kernel code. It forces making the task selfcontained. There is no longer an

Workqueues have clean and rich API for all basic operations. The code is usually easier and better readable. It can be easily tuned for the given purpose. In many cases, it allows to avoid an extra kernel thread. It helps to stop the growing number of them. Also there will be less thread-specific hacks all over the kernel code. It forces making the task selfcontained. There is no longer an

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 is being restored. It means that most of the balloon stays leaked after the system freeze and restore. This

Workqueues have clean and rich API for all basic operations. The code is usually easier and better readable. It can be easily tuned for the given purpose. In many cases, it allows to avoid an extra kernel thread. It helps to stop the growing number of them. Also there will be less thread-specific hacks all over the kernel code. It forces making the task selfcontained. There is no longer an

Workqueues have clean and rich API for all basic operations. The code is usually easier and better readable. It can be easily tuned for the given purpose. In many cases, it allows to avoid an extra kernel thread. It helps to stop the growing number of them. Also there will be less thread-specific hacks all over the kernel code. It forces making the task selfcontained. There is no longer an

From: Petr Mladek <pmladek at suse.cz> This patch moves the deferred work from the "vballoon" kthread into a system freezable workqueue. We do not need to maintain and run a dedicated kthread. Also the event driven workqueues API makes the logic much easier. Especially, we do not longer need an own wait queue, wait function, and freeze point. The conversion is pretty

On Fri, Dec 04, 2015 at 02:37:51PM +0100, Petr Mladek wrote: > From: Petr Mladek <pmladek at suse.cz> > > This patch moves the deferred work from the "vballoon" kthread into a > system freezable workqueue. > > We do not need to maintain and run a dedicated kthread. Also the event > driven workqueues API makes the logic much easier. Especially, we do > not

On Fri, Dec 04, 2015 at 02:37:51PM +0100, Petr Mladek wrote: > From: Petr Mladek <pmladek at suse.cz> > > This patch moves the deferred work from the "vballoon" kthread into a > system freezable workqueue. > > We do not need to maintain and run a dedicated kthread. Also the event > driven workqueues API makes the logic much easier. Especially, we do > not

On Wed, Nov 12, 2014 at 02:02:48PM +0100, Petr Mladek wrote: > Workqueues have clean and rich API for all basic operations. The code is usually > easier and better readable. It can be easily tuned for the given purpose. > > In many cases, it allows to avoid an extra kernel thread. It helps to stop the > growing number of them. Also there will be less thread-specific hacks all over

On Thu, Nov 20, 2014 at 05:55:58PM +0100, Petr Mladek wrote: > On Thu 2014-11-20 11:29:35, Tejun Heo wrote: > > On Thu, Nov 20, 2014 at 06:26:24PM +0200, Michael S. Tsirkin wrote: > > > On Thu, Nov 20, 2014 at 06:25:43PM +0200, Michael S. Tsirkin wrote: > > > > On Thu, Nov 20, 2014 at 11:07:46AM -0500, Tejun Heo wrote: > > > > > On Thu, Nov 20, 2014 at

On Thu, Nov 20, 2014 at 05:55:58PM +0100, Petr Mladek wrote: > On Thu 2014-11-20 11:29:35, Tejun Heo wrote: > > On Thu, Nov 20, 2014 at 06:26:24PM +0200, Michael S. Tsirkin wrote: > > > On Thu, Nov 20, 2014 at 06:25:43PM +0200, Michael S. Tsirkin wrote: > > > > On Thu, Nov 20, 2014 at 11:07:46AM -0500, Tejun Heo wrote: > > > > > On Thu, Nov 20, 2014 at