similar to: [PATCH v3] virtio_balloon: Convert "vballoon" kthread into a workqueue

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

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

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

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

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

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

On Wed, Oct 18, 2017 at 07:59:23PM +0900, Tetsuo Handa wrote: > 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 > >

On Sat 2016-01-02 23:36:03, Michael S. Tsirkin wrote: > On Sat, Jan 02, 2016 at 06:43:16AM -0500, Tejun Heo wrote: > > On Fri, Jan 01, 2016 at 12:18:17PM +0200, Michael S. Tsirkin wrote: > > > > My initial idea was to use a dedicated workqueue. Michael S. Tsirkin > > > > @@ -563,7 +534,7 @@ static void virtballoon_remove(struct virtio_device *vdev) > > >

Hello, On Fri, Jan 01, 2016 at 12:18:17PM +0200, Michael S. Tsirkin wrote: > > My initial idea was to use a dedicated workqueue. Michael S. Tsirkin > > suggested using a system one. Tejun Heo confirmed that the system > > workqueue has a pretty high concurrency level (256) by default. > > Therefore we need not be afraid of too long blocking. > > Right but fill has a

The balloon_lock was used to synchronize the access demand to elements of struct virtio_balloon and its queue operations (please see commit e22504296d). This prevents the concurrent run of the leak_balloon and fill_balloon functions, thereby resulting in a deadlock issue on OOM: fill_balloon: take balloon_lock and wait for OOM to get some memory; oom_notify: release some inflated memory via

On Sat, Jan 02, 2016 at 06:43:16AM -0500, Tejun Heo wrote: > Hello, > > On Fri, Jan 01, 2016 at 12:18:17PM +0200, Michael S. Tsirkin wrote: > > > My initial idea was to use a dedicated workqueue. Michael S. Tsirkin > > > suggested using a system one. Tejun Heo confirmed that the system > > > workqueue has a pretty high concurrency level (256) by default. >

On Sat, Jan 02, 2016 at 06:43:16AM -0500, Tejun Heo wrote: > Hello, > > On Fri, Jan 01, 2016 at 12:18:17PM +0200, Michael S. Tsirkin wrote: > > > My initial idea was to use a dedicated workqueue. Michael S. Tsirkin > > > suggested using a system one. Tejun Heo confirmed that the system > > > workqueue has a pretty high concurrency level (256) by default. >

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

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