From: Tejun Heo <tj@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Petr Mladek <pmladek@suse.com>, Jiri Kosina <jkosina@suse.cz>,
linux-kernel@vger.kernel.org, Petr Mladek <pmladek@suse.cz>,
virtualization@lists.linux-foundation.org,
Jeff Epler <jepler@unpythonic.net>
Subject: Re: [PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread
Date: Sat, 2 Jan 2016 06:43:16 -0500 [thread overview]
Message-ID: <20160102114316.GC3660@htj.duckdns.org> (raw)
In-Reply-To: <20160101121432-mutt-send-email-mst@redhat.com>
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 1/5 second sleep on failure - *that*
> is problematic for a system queue.
Why so? As long as the maximum concurrently used workers are not
high, 1/5 second or even a lot longer sleeps are completely fine.
> > @@ -563,7 +534,7 @@ static void virtballoon_remove(struct virtio_device *vdev)
> > struct virtio_balloon *vb = vdev->priv;
> >
> > unregister_oom_notifier(&vb->nb);
> > - kthread_stop(vb->thread);
> > + cancel_work_sync(&vb->wq_work);
>
> OK but since job requeues itself, cancelling like this might not be enough.
As long as there's no further external queueing, cancel_work_sync() is
guaranteed to kill a self-requeueing work item.
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Petr Mladek <pmladek@suse.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Jeff Epler <jepler@unpythonic.net>, Jiri Kosina <jkosina@suse.cz>,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, Petr Mladek <pmladek@suse.cz>
Subject: Re: [PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread
Date: Sat, 2 Jan 2016 06:43:16 -0500 [thread overview]
Message-ID: <20160102114316.GC3660@htj.duckdns.org> (raw)
In-Reply-To: <20160101121432-mutt-send-email-mst@redhat.com>
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 1/5 second sleep on failure - *that*
> is problematic for a system queue.
Why so? As long as the maximum concurrently used workers are not
high, 1/5 second or even a lot longer sleeps are completely fine.
> > @@ -563,7 +534,7 @@ static void virtballoon_remove(struct virtio_device *vdev)
> > struct virtio_balloon *vb = vdev->priv;
> >
> > unregister_oom_notifier(&vb->nb);
> > - kthread_stop(vb->thread);
> > + cancel_work_sync(&vb->wq_work);
>
> OK but since job requeues itself, cancelling like this might not be enough.
As long as there's no further external queueing, cancel_work_sync() is
guaranteed to kill a self-requeueing work item.
Thanks.
--
tejun
next prev parent reply other threads:[~2016-01-02 11:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 13:37 [PATCH v4 0/2] virtio_balloon: Fix restore and convert to workqueue Petr Mladek
2015-12-04 13:37 ` [PATCH v4 1/2] virtio_balloon: Restore the entire balloon after the system freeze Petr Mladek
2016-01-01 10:11 ` Michael S. Tsirkin
2016-01-01 10:11 ` Michael S. Tsirkin
2016-01-01 10:11 ` Michael S. Tsirkin
2016-01-01 10:11 ` Michael S. Tsirkin
2015-12-04 13:37 ` Petr Mladek
2015-12-04 13:37 ` [PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread Petr Mladek
2016-01-01 10:18 ` Michael S. Tsirkin
2016-01-01 10:18 ` Michael S. Tsirkin
2016-01-02 11:43 ` Tejun Heo [this message]
2016-01-02 11:43 ` Tejun Heo
2016-01-02 21:36 ` Michael S. Tsirkin
2016-01-02 21:36 ` Michael S. Tsirkin
2016-01-03 13:58 ` Tejun Heo
2016-01-03 13:58 ` Tejun Heo
2016-01-05 14:49 ` Petr Mladek
2016-01-05 14:49 ` Petr Mladek
2016-01-05 15:37 ` Michael S. Tsirkin
2016-01-05 15:37 ` Michael S. Tsirkin
2015-12-04 13:37 ` Petr Mladek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160102114316.GC3660@htj.duckdns.org \
--to=tj@kernel.org \
--cc=jepler@unpythonic.net \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=pmladek@suse.com \
--cc=pmladek@suse.cz \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.