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 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.