qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

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