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

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

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

Hello, Michael, Petr. On Wed, Nov 12, 2014 at 03:32:04PM +0200, Michael S. Tsirkin wrote: > > + /* The workqueue servicing the balloon. */ > > + struct workqueue_struct *wq; > > + struct work_struct wq_work; > > We could use system_freezable_wq instead. > I do agree a dedicated wq is better since this can get blocked > for a long time while allocating memory. >

Hello, Michael, Petr. On Wed, Nov 12, 2014 at 03:32:04PM +0200, Michael S. Tsirkin wrote: > > + /* The workqueue servicing the balloon. */ > > + struct workqueue_struct *wq; > > + struct work_struct wq_work; > > We could use system_freezable_wq instead. > I do agree a dedicated wq is better since this can get blocked > for a long time while allocating memory. >

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: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

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 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. >

Wei Wang wrote: > 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; >

Wei Wang wrote: > 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; >

fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize

fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize

fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize

fill_balloon doing memory allocations under balloon_lock can cause a deadlock when leak_balloon is called from virtballoon_oom_notify and tries to take same lock. To fix, split page allocation and enqueue and do allocations outside the lock. Here's a detailed analysis of the deadlock by Tetsuo Handa: In leak_balloon(), mutex_lock(&vb->balloon_lock) is called in order to serialize