From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: v9fs-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Marco Elver <elver@google.com>
Subject: Re: [PATCH] 9p/virtio: add a read barrier in p9_virtio_zc_request
Date: Tue, 13 Dec 2022 13:03:52 +0900 [thread overview]
Message-ID: <Y5f5qG1SkGrEST6H@codewreck.org> (raw)
In-Reply-To: <21422678.bhv4C0q8Fj@silver>
Christian Schoenebeck wrote on Mon, Dec 12, 2022 at 02:35:39PM +0100:
> > diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> > index 3c27ffb781e3..98425c63b3c3 100644
> > --- a/net/9p/trans_virtio.c
> > +++ b/net/9p/trans_virtio.c
> > @@ -533,6 +533,12 @@ p9_virtio_zc_request(struct p9_client *client, struct p9_req_t *req,
> > p9_debug(P9_DEBUG_TRANS, "virtio request kicked\n");
> > err = wait_event_killable(req->wq,
> > READ_ONCE(req->status) >= REQ_STATUS_RCVD);
> > +
> > + /* Make sure our req is coherent with regard to updates in other
> > + * threads - echoes to wmb() in the callback like p9_client_rpc
> > + */
> > + smp_rmb();
> > +
>
> Oh, I had p9_client_zc_rpc() for this in mind, but I see why you chose this
> place in p9_virtio_zc_request() instead. LGTM
Yes, we access req data here so as much as it'd make more sense to keep
it symetrical in p9_client_zc_rpc (like p9_client_rpc) I think we need
it here.
> I also made some tests to check whether this barrier would hurt performance,
> but I measured no difference. So this should be good to go:
Thanks!
The assembly generated with the barrier is actually slightly shorter for
x86_64, but it's hard to tell the actual performance impact....
> Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
Cheers, I've queued this patch as well: let's make that this merge
windows' batch unless a problem comes up.
--
Dominique
next prev parent reply other threads:[~2022-12-13 4:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-10 0:10 [PATCH] 9p/virtio: add a read barrier in p9_virtio_zc_request Dominique Martinet
2022-12-12 13:35 ` Christian Schoenebeck
2022-12-13 4:03 ` Dominique Martinet [this message]
[not found] <20221213065901.3523-1-hdanton@sina.com>
2022-12-13 11:00 ` Dominique Martinet
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=Y5f5qG1SkGrEST6H@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=elver@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=v9fs-developer@lists.sourceforge.net \
/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