From: Paolo Bonzini <pbonzini@redhat.com>
To: liu ping fan <qemulist@gmail.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug
Date: Wed, 26 Jun 2013 08:34:11 +0200 [thread overview]
Message-ID: <51CA8B63.6000501@redhat.com> (raw)
In-Reply-To: <CAJnKYQk6Ey=qjfRqYOJpoQFNH-rRoh7K36gKouYjTQQK5D=CiA@mail.gmail.com>
Il 26/06/2013 04:59, liu ping fan ha scritto:
>> The latter part could be the hard one in a multi-threaded context, but I
>> think it's up to the device to ensure it. It doesn't _have_ to be hard.
>> For example, joining the data-plane thread would do that as well.
>>
> It seems not easy, take consideration of the sequence:
> _bh_delete(), // ensure not scheduled, ie, no further access to DeviceState
> wait for rcu grace period to come, // ensure not running
> free DeviceState in rcu-reclaimer
> But in current code, _delete() can be placed in DeviceState
> finalization path(in reclaimer), which means while reclaiming, there
> still exist access path to the DeviceState.
It can be placed there, but it doesn't mean it is a good idea. :)
> On the other hand, pushing _delete() out of finalization path is not
> easy, since we do not what time the DeviceState has done with its bh.
See above:
- if the BH will run in the iothread, the BH is definitely not running
(because the BH runs under the BQL, and the reclaimer owns it)
- if the BH is running in another thread, waiting for that thread to
terminate obviously makes the BH not running.
What we need is separation of removal and reclamation. Without that,
any effort to make things unplug-safe is going to be way way more
complicated than necessary.
Paolo
next prev parent reply other threads:[~2013-06-26 6:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-25 17:38 [Qemu-devel] [PATCH 0/3] make bh safe with hot-unplug Liu Ping Fan
2013-06-25 6:24 ` Paolo Bonzini
2013-06-25 6:32 ` liu ping fan
2013-06-25 7:53 ` Paolo Bonzini
2013-06-26 2:59 ` liu ping fan
2013-06-26 6:34 ` Paolo Bonzini [this message]
2013-06-26 8:20 ` liu ping fan
2013-06-26 8:38 ` Paolo Bonzini
2013-06-26 9:44 ` liu ping fan
2013-06-26 9:55 ` Paolo Bonzini
2013-06-27 2:08 ` liu ping fan
2013-06-27 6:59 ` Paolo Bonzini
2013-06-25 17:38 ` [Qemu-devel] [PATCH 1/3] QEMUBH: introduce canceled member for bh Liu Ping Fan
2013-06-25 17:38 ` [Qemu-devel] [PATCH 2/3] QEMUBH: pin bh's referring object while scheduling Liu Ping Fan
2013-06-25 17:38 ` [Qemu-devel] [PATCH 3/3] virtio-net: set referred object for virtio net's bh Liu Ping Fan
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=51CA8B63.6000501@redhat.com \
--to=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.com \
--cc=stefanha@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).