similar to: [PATCH v2] virtio-balloon: do not call blocking ops when !TASK_RUNNING

Displaying 20 results from an estimated 3000 matches similar to: "[PATCH v2] virtio-balloon: do not call blocking ops when !TASK_RUNNING"

2015 Feb 25
2
[PATCH] virtio-balloon: do not call blocking ops when !TASK_RUNNING
virtio balloon has this code: wait_event_interruptible(vb->config_change, (diff = towards_target(vb)) != 0 || vb->need_stats_update || kthread_should_stop() || freezing(current)); Which is a problem because towards_target() call might block after
2015 Feb 25
2
[PATCH] virtio-balloon: do not call blocking ops when !TASK_RUNNING
virtio balloon has this code: wait_event_interruptible(vb->config_change, (diff = towards_target(vb)) != 0 || vb->need_stats_update || kthread_should_stop() || freezing(current)); Which is a problem because towards_target() call might block after
2015 Feb 26
1
virtio balloon: do not call blocking ops when !TASK_RUNNING
On Thu, Feb 26, 2015 at 06:08:49PM +0100, Peter Zijlstra wrote: > On Thu, Feb 26, 2015 at 09:30:31AM +0100, Michael S. Tsirkin wrote: > > On Thu, Feb 26, 2015 at 11:50:42AM +1030, Rusty Russell wrote: > > > Thomas Huth <thuth at linux.vnet.ibm.com> writes: > > > > Hi all, > > > > > > > > with the recent kernel 3.19, I get a kernel
2015 Feb 26
1
virtio balloon: do not call blocking ops when !TASK_RUNNING
On Thu, Feb 26, 2015 at 06:08:49PM +0100, Peter Zijlstra wrote: > On Thu, Feb 26, 2015 at 09:30:31AM +0100, Michael S. Tsirkin wrote: > > On Thu, Feb 26, 2015 at 11:50:42AM +1030, Rusty Russell wrote: > > > Thomas Huth <thuth at linux.vnet.ibm.com> writes: > > > > Hi all, > > > > > > > > with the recent kernel 3.19, I get a kernel
2015 Feb 25
1
[PATCH v2] virtio-balloon: do not call blocking ops when !TASK_RUNNING
On Wed, 25 Feb 2015 16:11:27 +0100 Cornelia Huck <cornelia.huck at de.ibm.com> wrote: > On Wed, 25 Feb 2015 15:36:02 +0100 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > virtio balloon has this code: > > wait_event_interruptible(vb->config_change, > > (diff = towards_target(vb)) != 0 > >
2015 Feb 25
1
[PATCH v2] virtio-balloon: do not call blocking ops when !TASK_RUNNING
On Wed, 25 Feb 2015 16:11:27 +0100 Cornelia Huck <cornelia.huck at de.ibm.com> wrote: > On Wed, 25 Feb 2015 15:36:02 +0100 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > virtio balloon has this code: > > wait_event_interruptible(vb->config_change, > > (diff = towards_target(vb)) != 0 > >
2015 Feb 25
0
[PATCH] virtio-balloon: do not call blocking ops when !TASK_RUNNING
On Wed, 25 Feb 2015 15:14:36 +0100 "Michael S. Tsirkin" <mst at redhat.com> wrote: > virtio balloon has this code: > wait_event_interruptible(vb->config_change, > (diff = towards_target(vb)) != 0 > || vb->need_stats_update > || kthread_should_stop() >
2015 Feb 25
0
[PATCH] virtio-balloon: do not call blocking ops when !TASK_RUNNING
On Wed, 25 Feb 2015 15:14:36 +0100 "Michael S. Tsirkin" <mst at redhat.com> wrote: > virtio balloon has this code: > wait_event_interruptible(vb->config_change, > (diff = towards_target(vb)) != 0 > || vb->need_stats_update > || kthread_should_stop() >
2015 Feb 26
2
virtio balloon: do not call blocking ops when !TASK_RUNNING
On Thu, Feb 26, 2015 at 11:50:42AM +1030, Rusty Russell wrote: > Thomas Huth <thuth at linux.vnet.ibm.com> writes: > > Hi all, > > > > with the recent kernel 3.19, I get a kernel warning when I start my > > KVM guest on s390 with virtio balloon enabled: > > The deeper problem is that virtio_ccw_get_config just silently fails on > OOM. > > Neither
2015 Feb 26
2
virtio balloon: do not call blocking ops when !TASK_RUNNING
On Thu, Feb 26, 2015 at 11:50:42AM +1030, Rusty Russell wrote: > Thomas Huth <thuth at linux.vnet.ibm.com> writes: > > Hi all, > > > > with the recent kernel 3.19, I get a kernel warning when I start my > > KVM guest on s390 with virtio balloon enabled: > > The deeper problem is that virtio_ccw_get_config just silently fails on > OOM. > > Neither
2015 Feb 25
0
[PATCH v2] virtio-balloon: do not call blocking ops when !TASK_RUNNING
On Wed, 25 Feb 2015 15:36:02 +0100 "Michael S. Tsirkin" <mst at redhat.com> wrote: > virtio balloon has this code: > wait_event_interruptible(vb->config_change, > (diff = towards_target(vb)) != 0 > || vb->need_stats_update > || kthread_should_stop() >
2015 Feb 25
0
[PATCH v2] virtio-balloon: do not call blocking ops when !TASK_RUNNING
On Wed, 25 Feb 2015 15:36:02 +0100 "Michael S. Tsirkin" <mst at redhat.com> wrote: > virtio balloon has this code: > wait_event_interruptible(vb->config_change, > (diff = towards_target(vb)) != 0 > || vb->need_stats_update > || kthread_should_stop() >
2015 Feb 25
7
virtio balloon: do not call blocking ops when !TASK_RUNNING
Hi all, with the recent kernel 3.19, I get a kernel warning when I start my KVM guest on s390 with virtio balloon enabled: [ 0.839687] do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000000174a1e>] prepare_to_wait_event+0x7e/0x108 [ 0.839694] ------------[ cut here ]------------ [ 0.839697] WARNING: at kernel/sched/core.c:7326 [ 0.839698]
2015 Feb 25
7
virtio balloon: do not call blocking ops when !TASK_RUNNING
Hi all, with the recent kernel 3.19, I get a kernel warning when I start my KVM guest on s390 with virtio balloon enabled: [ 0.839687] do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000000174a1e>] prepare_to_wait_event+0x7e/0x108 [ 0.839694] ------------[ cut here ]------------ [ 0.839697] WARNING: at kernel/sched/core.c:7326 [ 0.839698]
2015 Feb 26
0
virtio balloon: do not call blocking ops when !TASK_RUNNING
Thomas Huth <thuth at linux.vnet.ibm.com> writes: > Hi all, > > with the recent kernel 3.19, I get a kernel warning when I start my > KVM guest on s390 with virtio balloon enabled: The deeper problem is that virtio_ccw_get_config just silently fails on OOM. Neither get_config nor set_config are expected to fail. Cornelia, I think ccw and config_area should be allocated inside
2015 Feb 26
0
virtio balloon: do not call blocking ops when !TASK_RUNNING
Thomas Huth <thuth at linux.vnet.ibm.com> writes: > Hi all, > > with the recent kernel 3.19, I get a kernel warning when I start my > KVM guest on s390 with virtio balloon enabled: The deeper problem is that virtio_ccw_get_config just silently fails on OOM. Neither get_config nor set_config are expected to fail. Cornelia, I think ccw and config_area should be allocated inside
2014 Nov 12
3
[PATCH v2] 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
2014 Nov 12
3
[PATCH v2] 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
2015 Dec 04
0
[PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread
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
2016 Jan 01
2
[PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread
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