From: Paolo Bonzini <pbonzini@redhat.com>
To: Ming Lei <tom.leiming@gmail.com>,
Linux SCSI List <linux-scsi@vger.kernel.org>,
Wanlong Gao <gaowanlong@cn.fujitsu.com>,
Asias He <asias@redhat.com>,
"James E.J. Bottomley" <JBottomley@parallels.com>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: virtio-scsi: two questions related with picking up queue
Date: Tue, 06 May 2014 15:17:15 +0200 [thread overview]
Message-ID: <5368E0DB.5010000@redhat.com> (raw)
In-Reply-To: <CACVXFVNeBbJgA6h5n1Mt7vp7_Es67N5KEpZ0en4O+9GnD6wp+A@mail.gmail.com>
Il 06/05/2014 11:26, Ming Lei ha scritto:
> Hi Paolo and All,
>
> One question is about ACCESS_ONCE() in virtscsi_pick_vq(),
> looks it needn't since both reading and writing tgt->req_vq holds
> tgt->tgt_lock.
You're right. It should be possible to avoid the lock in
virtscsi_pick_vq like this:
value = atomic_read(&tgt->reqs);
retry:
if (value != 0) {
old_value = atomic_cmpxchg(&tgt->regs, value, value + 1)
if (old_value != value) {
value = old_value;
goto retry;
}
smp_mb__after_atomic_cmpxchg(); // you get the idea :)
vq = ACCESS_ONCE(tgt->req_vq);
} else {
spin_lock_irqsave(&tgt->tgt_lock, flags);
// tgt->reqs may not be 0 anymore, need to recheck
value = atomic_read(&tgt->reqs);
if (atomic_read(&tgt->reqs) != 0) {
spin_unlock_irqrestore(&tgt->tgt_lock, flags);
goto retry;
}
// tgt->reqs now will remain fixed to 0.
...
tgt->req_vq = vq = ...;
smp_wmb();
atomic_set(&tgt->reqs, 1);
spin_unlock_irqrestore(&tgt->tgt_lock, flags);
}
return vq;
and then you would need the ACCESS_ONCE but I'm not sure it's worthwhile.
> Another one is about the comment in virtscsi_req_done(), which
> said smp_read_barrier_depends() is needed for avoiding
> out of order between reading req_vq and decreasing tgt->reqs.
> But if I understand correctly, in virtscsi_req_done(), req_vq is
> read from vscsi->req_vqs[vq->index - VIRTIO_SCSI_VQ_BASE],
> instead of tgt->req_vq, and the former won't change wrt.
> inc/dec tgt->reqs, so can the barrier be removed?
Right. The comment is obsolete and dates to before vq->index existed.
Paolo
> Any comments about the above?
>
> Thanks,
>
next prev parent reply other threads:[~2014-05-06 13:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-06 9:26 virtio-scsi: two questions related with picking up queue Ming Lei
2014-05-06 13:17 ` Paolo Bonzini [this message]
2014-05-07 1:07 ` Ming Lei
2014-05-07 7:10 ` Paolo Bonzini
2014-05-07 16:24 ` Ming Lei
2014-05-07 16:43 ` Paolo Bonzini
2014-05-08 10:44 ` Ming Lei
2014-05-08 12:17 ` Paolo Bonzini
2014-05-08 12:55 ` Ming Lei
2014-05-08 13:21 ` Paolo Bonzini
2014-05-08 14:00 ` 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=5368E0DB.5010000@redhat.com \
--to=pbonzini@redhat.com \
--cc=JBottomley@parallels.com \
--cc=asias@redhat.com \
--cc=gaowanlong@cn.fujitsu.com \
--cc=linux-scsi@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=tom.leiming@gmail.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 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.