From: Ming Lei <tom.leiming@gmail.com>
To: "James E.J. Bottomley" <JBottomley@parallels.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-scsi@vger.kernel.org,
Wanlong Gao <gaowanlong@cn.fujitsu.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Ming Lei <tom.leiming@gmail.com>
Subject: [PATCH 2/2] virtio_scsi: remove smp_read_barrier_depends
Date: Wed, 7 May 2014 22:13:09 +0800 [thread overview]
Message-ID: <1399471989-17890-1-git-send-email-tom.leiming@gmail.com> (raw)
The barrier in virtscsi_req_done was introduced to
order reading req_vq and decreasing tgt->reqs, but
it isn't needed now because req_vq is read from
scsi->req_vqs[vq->index - VIRTIO_SCSI_VQ_BASE]
instead of tgt->req_vq, so remove the unnecessary
barrier.
Also remove related comment about the barrier.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
drivers/scsi/virtio_scsi.c | 52 +++-----------------------------------------
1 file changed, 3 insertions(+), 49 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index aead20f..0c77ed6 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -73,19 +73,9 @@ struct virtio_scsi_vq {
* queue, and also lets the driver optimize the IRQ affinity for the virtqueues
* (each virtqueue's affinity is set to the CPU that "owns" the queue).
*
- * An interesting effect of this policy is that only writes to req_vq need to
- * take the tgt_lock. Read can be done outside the lock because:
- *
- * - writes of req_vq only occur when atomic_inc_return(&tgt->reqs) returns 1.
- * In that case, no other CPU is reading req_vq: even if they were in
- * virtscsi_queuecommand_multi, they would be spinning on tgt_lock.
- *
- * - reads of req_vq only occur when the target is not idle (reqs != 0).
- * A CPU that enters virtscsi_queuecommand_multi will not modify req_vq.
- *
- * Similarly, decrements of reqs are never concurrent with writes of req_vq.
- * Thus they can happen outside the tgt_lock, provided of course we make reqs
- * an atomic_t.
+ * tgt_lock is held to serialize reading and writing req_vq, and reading
+ * req_vq should have been done concurrently, but need a bit complicated
+ * trick.
*/
struct virtio_scsi_target_state {
/* This spinlock never held at the same time as vq_lock. */
@@ -238,38 +228,6 @@ static void virtscsi_req_done(struct virtqueue *vq)
int index = vq->index - VIRTIO_SCSI_VQ_BASE;
struct virtio_scsi_vq *req_vq = &vscsi->req_vqs[index];
- /*
- * Read req_vq before decrementing the reqs field in
- * virtscsi_complete_cmd.
- *
- * With barriers:
- *
- * CPU #0 virtscsi_queuecommand_multi (CPU #1)
- * ------------------------------------------------------------
- * lock vq_lock
- * read req_vq
- * read reqs (reqs = 1)
- * write reqs (reqs = 0)
- * increment reqs (reqs = 1)
- * write req_vq
- *
- * Possible reordering without barriers:
- *
- * CPU #0 virtscsi_queuecommand_multi (CPU #1)
- * ------------------------------------------------------------
- * lock vq_lock
- * read reqs (reqs = 1)
- * write reqs (reqs = 0)
- * increment reqs (reqs = 1)
- * write req_vq
- * read (wrong) req_vq
- *
- * We do not need a full smp_rmb, because req_vq is required to get
- * to tgt->reqs: tgt is &vscsi->tgt[sc->device->id], where sc is stored
- * in the virtqueue as the user token.
- */
- smp_read_barrier_depends();
-
virtscsi_vq_done(vscsi, req_vq, virtscsi_complete_cmd);
};
@@ -560,10 +518,6 @@ static struct virtio_scsi_vq *virtscsi_pick_vq(struct virtio_scsi *vscsi,
spin_lock_irqsave(&tgt->tgt_lock, flags);
- /*
- * The memory barrier after atomic_inc_return matches
- * the smp_read_barrier_depends() in virtscsi_req_done.
- */
if (atomic_inc_return(&tgt->reqs) > 1)
vq = tgt->req_vq;
else {
--
1.7.9.5
next reply other threads:[~2014-05-07 14:13 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-07 14:13 Ming Lei [this message]
2014-05-07 14:18 ` [PATCH 2/2] virtio_scsi: remove smp_read_barrier_depends Paolo Bonzini
2014-05-07 14:36 ` Ming Lei
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=1399471989-17890-1-git-send-email-tom.leiming@gmail.com \
--to=tom.leiming@gmail.com \
--cc=JBottomley@parallels.com \
--cc=gaowanlong@cn.fujitsu.com \
--cc=linux-scsi@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rusty@rustcorp.com.au \
/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