From: Heiner Kallweit <hkallweit1@gmail.com>
To: Chaitanya Kulkarni <Chaitanya.Kulkarni@wdc.com>,
Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>
Cc: "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: [PATCH] nvme: use lighter smp barriers in nvme_irq
Date: Wed, 17 Feb 2021 08:26:30 +0100 [thread overview]
Message-ID: <be263cdf-19a2-05d6-1023-7d935d526663@gmail.com> (raw)
In-Reply-To: <BYAPR04MB4965D222B05866D93852835F86879@BYAPR04MB4965.namprd04.prod.outlook.com>
On 17.02.2021 00:59, Chaitanya Kulkarni wrote:
> On 2/14/21 08:30, Heiner Kallweit wrote:
>> Based on the description we should be fine using the less heavy-weight
>> smp barriers here. On x86 this would be compiler barriers only.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> Can you share performance numbers ?
>
I stumbled across this code piece by chance and don't have hw to test it.
Having said that the change is based on code inspection only.
Unfortunately the barrier comment is very generic and doesn't mention
a problematic scenario. Also the commit message of 3a7afd8ee42a doesn't
mention a potential race. Most likely the barrier can be removed
completely. Helpful would be if someone could explain the potential race
in detail, means which reordering / variable accesses could be racy.
Then we would have a basis to talk about READ_ONCE/WRITE_ONCE vs.
smp barrier vs. dma barrier vs. full barrier.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-02-17 7:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-14 16:24 [PATCH] nvme: use lighter smp barriers in nvme_irq Heiner Kallweit
2021-02-16 23:59 ` Chaitanya Kulkarni
2021-02-17 7:26 ` Heiner Kallweit [this message]
2021-02-18 1:41 ` Chaitanya Kulkarni
2021-02-18 3:28 ` Keith Busch
2021-02-18 4:06 ` Chaitanya Kulkarni
2021-02-18 21:57 ` Keith Busch
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=be263cdf-19a2-05d6-1023-7d935d526663@gmail.com \
--to=hkallweit1@gmail.com \
--cc=Chaitanya.Kulkarni@wdc.com \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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