search for: workqueues

Introduce a helper to retrieve the current task's work struct if it is a workqueue worker. This allows us to fix a long-standing deadlock in several DRM drivers wherein the ->runtime_suspend callback waits for a specific worker to finish and that worker in turn calls a function which waits for runtime suspend to finish. That function is invoked from multiple call sites and waiting for

FYI, it is likely that ocfs2 will not work on 3.7-rcN until the following one-line patch is merged, as the code in ramster that provoked it is directly leveraged from ocfs2 o2net. > From: Tejun Heo [mailto:tj at kernel.org] > Sent: Thursday, October 18, 2012 5:39 PM > To: Dan Magenheimer > Cc: linux-kernel at vger.kernel.org; Konrad Wilk > Subject: [PATCH] workqueue:

...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. > However, please add a comment to this effect. system_freezable_wq should be fine. Workqueues by default have a pretty high maximum concurrency level (256). There's no reason to create separate workqueues solely for that purpose. Thanks. -- tejun

...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. > However, please add a comment to this effect. system_freezable_wq should be fine. Workqueues by default have a pretty high maximum concurrency level (256). There's no reason to create separate workqueues solely for that purpose. Thanks. -- tejun

...: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 longer need an own wait queue, wait function, and freeze point. > > The conversion is pretty straightforward. One cycle of the main loop > is put into a work. The work is queued instead of waking the kthread. > > fill_ball...

...: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 longer need an own wait queue, wait function, and freeze point. > > The conversion is pretty straightforward. One cycle of the main loop > is put into a work. The work is queued instead of waking the kthread. > > fill_ball...

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

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 straightforward. One cycle of the main loop is put into a work. The work is queued instead of waking the kthread. fill_balloon() and leak_balloon() have...

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

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

On Thu, Nov 20, 2014 at 06:47:11PM +0200, Michael S. Tsirkin wrote: > > There's cancel_work_sync() to stop the self-requeueing ones. > > What happens if queue_work runs while cancel_work_sync is in progress? > Does it fail to queue? cancel_work_sync() is guaranteed to take self-requeueing work items no matter when it's called or what's going on. External (non-self)

On Thu, Nov 20, 2014 at 06:47:11PM +0200, Michael S. Tsirkin wrote: > > There's cancel_work_sync() to stop the self-requeueing ones. > > What happens if queue_work runs while cancel_work_sync is in progress? > Does it fail to queue? cancel_work_sync() is guaranteed to take self-requeueing work items no matter when it's called or what's going on. External (non-self)

Hello. On 10/5/2014 8:07 PM, Michael S. Tsirkin wrote: > config_mutex served two purposes: prevent multiple concurrent config > change handlers, and synchronize access to config_enable flag. > Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1 > workqueue: make all workqueues non-reentrant > all workqueues are non-reentrant, and config_enable > is now gone. > Get rid of the unnecessary lock. > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/net/virtio_net.c | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-...

Hello. On 10/5/2014 8:07 PM, Michael S. Tsirkin wrote: > config_mutex served two purposes: prevent multiple concurrent config > change handlers, and synchronize access to config_enable flag. > Since commit dbf2576e37da0fcc7aacbfbb9fd5d3de7888a3c1 > workqueue: make all workqueues non-reentrant > all workqueues are non-reentrant, and config_enable > is now gone. > Get rid of the unnecessary lock. > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/net/virtio_net.c | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-...

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

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

On 02/06/2015 09:49 AM, Raghavendra K T wrote: > Paravirt spinlock clears slowpath flag after doing unlock. > As explained by Linus currently it does: > prev = *lock; > add_smp(&lock->tickets.head, TICKET_LOCK_INC); > > /* add_smp() is a full mb() */ > > if (unlikely(lock->tickets.tail &

On 02/06/2015 09:49 AM, Raghavendra K T wrote: > Paravirt spinlock clears slowpath flag after doing unlock. > As explained by Linus currently it does: > prev = *lock; > add_smp(&lock->tickets.head, TICKET_LOCK_INC); > > /* add_smp() is a full mb() */ > > if (unlikely(lock->tickets.tail &

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