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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox