qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH 3/3] virtio-scsi-dataplane: Use main thread BH to set BDS' aio context
Date: Fri, 13 Feb 2015 11:38:18 +0100	[thread overview]
Message-ID: <54DDD41A.3080106@redhat.com> (raw)
In-Reply-To: <20150213102941.GA19672@ad.nay.redhat.com>



On 13/02/2015 11:29, Fam Zheng wrote:
> I think we should avoid duplicate everything on both virtio-blk and
> virtio-scsi, so they will have differences.

True, but there are also similarities.  virtio-blk can also do per-VQ
iothreads

> Why do you think Per VQ iothread is far away?

Because per-VQ iothread needs to use either fine-grained locks or,
especially in the format and protocol driver, no locks at all.  No locks
at all applies especially to the raw case, where we can more easily
leverage kernel-side locks and thread-local storage.

Right now the lock is per-AioContext, but even if you made it
BlockBackend-grained lock, the iothreads will just contend on it and
each device won't get better performance than a single iothread.  Making
a single backend faster is unfortunately an extremely important case; if
you have multiple backends you can already move them to separate
virtio-scsi controllers or virtio-blk devices.

We haven't even started thinking how the design should look like, so I
think it's far away.

> Limiting to 1 thread for the
> whole scsi bus doesn't sound ultimate solution for me. I think it's not harder
> than the MMIO safety work we have, and also somehow independent to it.

I'm not sure it's independent.  While the MMIO safety work does not
imply using fine-grained locks, it probably(*) implies using
fine-grained critical sections.  Fine-grained critical sections are
probably(**) a subset of the work needed for fine-grained locks or also
for lockless operation.

	(*) probably = couldn't think of a better way

	(**) probably = I haven't even thought about it

Paolo

> But yes, stop using bdrv_set_aio_context will be the other way to make it
> right, just harder to do.

  reply	other threads:[~2015-02-13 10:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12  5:20 [Qemu-devel] [PATCH 0/3] virtio-scsi: Fix unsafe bdrv_set_aio_context calls Fam Zheng
2015-02-12  5:21 ` [Qemu-devel] [PATCH 1/3] block: Forbid bdrv_set_aio_context outside BQL Fam Zheng
2015-02-13 13:10   ` Paolo Bonzini
2015-03-10 13:34   ` Stefan Hajnoczi
2015-02-12  5:21 ` [Qemu-devel] [PATCH 2/3] virtio-scsi: Deduplicate cmd queue handling code of dataplane Fam Zheng
2015-02-12  5:21 ` [Qemu-devel] [PATCH 3/3] virtio-scsi-dataplane: Use main thread BH to set BDS' aio context Fam Zheng
2015-02-12 14:29   ` Paolo Bonzini
2015-02-13  1:21     ` Fam Zheng
2015-02-13  9:38       ` Paolo Bonzini
2015-02-13 10:29         ` Fam Zheng
2015-02-13 10:38           ` Paolo Bonzini [this message]
2015-02-13 12:42             ` Fam Zheng
2015-02-13 13:12               ` Paolo Bonzini

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=54DDD41A.3080106@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --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).