[PATCH] nvme: use lighter smp barriers in nvme_irq

[Chaitanya Kulkarni]

On 2/16/21 23:26, Heiner Kallweit wrote:
> 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 at 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.
>

For these question you need to add commit Author to original email, as
far as
I know any performance improvement needs to be backed by data, unless there
is an exception, in this case I'm not if it is.