From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Date: Mon, 04 Apr 2016 09:03:36 +0000 Subject: Re: [PATCH 02/11] locking, rwsem: drop explicit memory barriers Message-Id: <20160404090335.GB10272@dhcp22.suse.cz> List-Id: References: <1459508695-14915-1-git-send-email-mhocko@kernel.org> <1459508695-14915-3-git-send-email-mhocko@kernel.org> <20160402011753.GB5329@linux-uzut.site> In-Reply-To: <20160402011753.GB5329@linux-uzut.site> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Davidlohr Bueso Cc: LKML , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , "David S. Miller" , Tony Luck , Andrew Morton , Chris Zankel , Max Filippov , x86@kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org On Fri 01-04-16 18:17:53, Davidlohr Bueso wrote: [...] > I think we can actually get rid of these files altogether. While I > don't know the archs, it does not appear to be implementing any kind > of workaround/optimization, which is obviously the whole purpose of > defining per-arch rwsem internals, unless the redundant barriers are > actually the purpose. So we could use the generic rwsem.h (which has > optimizations and ACQUIRE/ RELEASE semantics, although nops for either > sh or xtensa specifically). A first inspection shows that the code is > in fact the same and continue to use 32bit rwsems. OK, so this has passed my defconfig and allnoconfig for xtensa compile test, allyesconfig has failed due to some unrelated reasons: clk-qoriq.c:(.init.text+0x3ebd3): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x17c60) and zillions of similar... The same error is without the patch I do not have a crosscompiler[1] for sh arch so I couldn't have tested it but there shouldn't be any issues in principal. I will send two patches as a follow up. --- [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/ doesn't seem to have it. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932183AbcDDJDo (ORCPT ); Mon, 4 Apr 2016 05:03:44 -0400 Received: from mail-lb0-f193.google.com ([209.85.217.193]:36334 "EHLO mail-lb0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754169AbcDDJDk (ORCPT ); Mon, 4 Apr 2016 05:03:40 -0400 Date: Mon, 4 Apr 2016 11:03:36 +0200 From: Michal Hocko To: Davidlohr Bueso Cc: LKML , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , "David S. Miller" , Tony Luck , Andrew Morton , Chris Zankel , Max Filippov , x86@kernel.org, linux-alpha@vger.kernel.org, linux-ia64@vger.kernel.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, linux-arch@vger.kernel.org Subject: Re: [PATCH 02/11] locking, rwsem: drop explicit memory barriers Message-ID: <20160404090335.GB10272@dhcp22.suse.cz> References: <1459508695-14915-1-git-send-email-mhocko@kernel.org> <1459508695-14915-3-git-send-email-mhocko@kernel.org> <20160402011753.GB5329@linux-uzut.site> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160402011753.GB5329@linux-uzut.site> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 01-04-16 18:17:53, Davidlohr Bueso wrote: [...] > I think we can actually get rid of these files altogether. While I > don't know the archs, it does not appear to be implementing any kind > of workaround/optimization, which is obviously the whole purpose of > defining per-arch rwsem internals, unless the redundant barriers are > actually the purpose. So we could use the generic rwsem.h (which has > optimizations and ACQUIRE/ RELEASE semantics, although nops for either > sh or xtensa specifically). A first inspection shows that the code is > in fact the same and continue to use 32bit rwsems. OK, so this has passed my defconfig and allnoconfig for xtensa compile test, allyesconfig has failed due to some unrelated reasons: clk-qoriq.c:(.init.text+0x3ebd3): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.init.literal+0x17c60) and zillions of similar... The same error is without the patch I do not have a crosscompiler[1] for sh arch so I couldn't have tested it but there shouldn't be any issues in principal. I will send two patches as a follow up. --- [1] https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/ doesn't seem to have it. -- Michal Hocko SUSE Labs