From: Davidlohr Bueso <dave@stgolabs.net>
To: dsterba@suse.cz, dsterba@suse.com, nborisov@suse.com,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Davidlohr Bueso <dbueso@suse.de>
Subject: Re: [PATCH] btrfs: optimize barrier usage for Rmw atomics
Date: Wed, 29 Jan 2020 11:25:50 -0800 [thread overview]
Message-ID: <20200129192550.nnfkkgde445nrbko@linux-p48b> (raw)
In-Reply-To: <20200129191439.GN3929@twin.jikos.cz>
On Wed, 29 Jan 2020, David Sterba wrote:
>On Wed, Jan 29, 2020 at 10:03:24AM -0800, Davidlohr Bueso wrote:
>> Use smp_mb__after_atomic() instead of smp_mb() and avoid the
>> unnecessary barrier for non LL/SC architectures, such as x86.
>
>So that's a conflicting advice from what we got when discussing wich
>barriers to use in 6282675e6708ec78518cc0e9ad1f1f73d7c5c53d and the
>memory is still fresh. My first idea was to take the
>smp_mb__after_atomic and __before_atomic variants and after discussion
>with various people the plain smp_wmb/smp_rmb were suggested and used in
>the end.
So the patch you mention deals with test_bit(), which is out of the scope
of smp_mb__{before,after}_atomic() as it's not a RMW operation. atomic_inc()
and set_bit() are, however, meant to use these barriers.
>
>I can dig the email threads and excerpts from irc conversations, maybe
>Nik has them at hand too. We do want to get rid of all unnecessary and
>uncommented barriers in btrfs code, so I appreciate your patch.
Yeah, I struggled with the amount of undocumented barriers, and decided
not to go down that rabbit hole. This patch is only an equivalent of
what is currently there. When possible, getting rid of barriers is of
course better.
Thanks,
Davidlohr
next prev parent reply other threads:[~2020-01-29 19:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-29 18:03 [PATCH] btrfs: optimize barrier usage for Rmw atomics Davidlohr Bueso
2020-01-29 19:07 ` Nikolay Borisov
2020-01-29 19:14 ` David Sterba
2020-01-29 19:25 ` Davidlohr Bueso [this message]
2020-01-29 23:55 ` Qu Wenruo
2020-01-30 8:18 ` Nikolay Borisov
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=20200129192550.nnfkkgde445nrbko@linux-p48b \
--to=dave@stgolabs.net \
--cc=dbueso@suse.de \
--cc=dsterba@suse.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nborisov@suse.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