Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Stefan Asserhall <stefana@xilinx.com>
To:     Peter Zijlstra <peterz@infradead.org>,
        Michal Simek <michals@xilinx.com>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "monstr@monstr.eu" <monstr@monstr.eu>, git <git@xilinx.com>,
        "arnd@arndb.de" <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Masahiro Yamada <yamada.masahiro@socionext.com>,
        Will Deacon <will@kernel.org>
Subject: RE: [PATCH 3/7] microblaze: Define SMP safe bit operations
Thread-Topic: [PATCH 3/7] microblaze: Define SMP safe bit operations
Thread-Index: AQHV4bsPPZw9y+9DiE+r7k7+xry4lagXtZWAgAEaGYCAAAMQYIAABNGAgAACQ6A=
Date:   Thu, 13 Feb 2020 09:24:46 +0000
Message-ID: <BYAPR02MB499726A42B20E172E3787C08DD1A0@BYAPR02MB4997.namprd02.prod.outlook.com>
References: <cover.1581522136.git.michal.simek@xilinx.com>
 <6a052c943197ed33db09ad42877e8a2b7dad6b96.1581522136.git.michal.simek@xilinx.com>
 <20200212155309.GA14973@hirez.programming.kicks-ass.net>
 <cd4c6117-bc61-620c-8477-44df6e51d7b8@xilinx.com>
 <BYAPR02MB499729CFF3B9FD7DDDCFBCD8DD1A0@BYAPR02MB4997.namprd02.prod.outlook.com>
 <20200213091101.GM14897@hirez.programming.kicks-ass.net>
In-Reply-To: <20200213091101.GM14897@hirez.programming.kicks-ass.net>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: xilinx.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 09d4f07d-fb20-4748-ac35-08d7b0669148
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2020 09:24:46.5517
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 657af505-d5df-48d0-8300-c31994686c5c
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LDyBXp1CdxOweG4TiPmSCz8/CjiuGa4XMgBUY+JBOfzpmOA9+VK+PX9z+TKMLHZr1lOhsZeXbCX4uhbhVYoscg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR02MB3944
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> On Thu, Feb 13, 2020 at 09:01:21AM +0000, Stefan Asserhall wrote:
> > The comment in the generic bitops.h says "You should recode these in
> > the native assembly language, if at all possible". I don't think using
> > the generic implementation will be as efficient as the current arch spe=
cific one.
>=20
> That is a very crusty old recommendation. Please look at the compiler gen=
erated
> code.
>=20
> We've extended the atomic_t operations the past few years and Will wrote =
the
> generic atomic bitops for Arm64, we're looking to convert more LL/SC arch=
s to
> them.
>=20
> There is currently one known issue with it, but Will has a patch-set pend=
ing to
> solve that (IIRC that only matters if you have stack protector on).
>=20
> Also see this thread:
>=20
>   https://lkml.kernel.org/r/875zimp0ay.fsf@mpe.ellerman.id.au
>=20
> And these patches:
>=20
>   https://lkml.kernel.org/r/20200123153341.19947-1-will@kernel.org

Thanks for the links. Sure, I agree that it is better to use the generic=20
implementation if it is as efficient as the arch specific one, but I don't
think we should assume that it is.

Michal, would it be possible to replace the arch specific code and check
what we get?

Stefan