From: Petr Mladek <pmladek@suse.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
Tejun Heo <tj@kernel.org>, Jeff Epler <jepler@unpythonic.net>
Subject: Re: [PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread
Date: Tue, 5 Jan 2016 15:49:18 +0100 [thread overview]
Message-ID: <20160105144918.GF3178@pathway.suse.cz> (raw)
In-Reply-To: <20160102213603.GA1703@redhat.com>
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)
> > > > 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.
>
> I didn't realise this. Thanks!
>
> Unfortunately in this case, there can be further requeueing
> if a stats request arrives.
Please, is there any point where the stat requests are disabled for
sure? I am not 100% sure but it might be after the reset() call:
vb->vdev->config->reset(vb->vdev);
Then we could split the kthread into two works: resizing and stats.
The resizing work still must be canceled before leaking the balloon.
But the stats work might be canceled after the reset() call.
In fact, the solution with the two works looks even cleaner.
Thanks for feedback,
Petr
WARNING: multiple messages have this Message-ID (diff)
From: Petr Mladek <pmladek@suse.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Tejun Heo <tj@kernel.org>, 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
Subject: Re: [PATCH v4 2/2] virtio_balloon: Use a workqueue instead of "vballoon" kthread
Date: Tue, 5 Jan 2016 15:49:18 +0100 [thread overview]
Message-ID: <20160105144918.GF3178@pathway.suse.cz> (raw)
In-Reply-To: <20160102213603.GA1703@redhat.com>
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)
> > > > 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.
>
> I didn't realise this. Thanks!
>
> Unfortunately in this case, there can be further requeueing
> if a stats request arrives.
Please, is there any point where the stat requests are disabled for
sure? I am not 100% sure but it might be after the reset() call:
vb->vdev->config->reset(vb->vdev);
Then we could split the kthread into two works: resizing and stats.
The resizing work still must be canceled before leaking the balloon.
But the stats work might be canceled after the reset() call.
In fact, the solution with the two works looks even cleaner.
Thanks for feedback,
Petr
next prev parent reply other threads:[~2016-01-05 14:49 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
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 [this message]
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=20160105144918.GF3178@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=jepler@unpythonic.net \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=tj@kernel.org \
--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.