From mboxrd@z Thu Jan 1 00:00:00 1970 From: Octavian Purdila Subject: Re: [RFC v3 01/26] asm-generic: atomic64: allow using generic atomic64 on 64bit platforms Date: Fri, 7 Feb 2020 14:32:20 +0200 Message-ID: References: <39e1313ff3cf3eab6ceb5ae322fcd3e5d4432167.1580882335.git.thehajime@gmail.com> <20200205093454.GG14879@hirez.programming.kicks-ass.net> <20200205124908.GL14879@hirez.programming.kicks-ass.net> <20200205171306.GP14879@hirez.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from mail-lj1-f196.google.com ([209.85.208.196]:35702 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726674AbgBGMcd (ORCPT ); Fri, 7 Feb 2020 07:32:33 -0500 Received: by mail-lj1-f196.google.com with SMTP id q8so1968726ljb.2 for ; Fri, 07 Feb 2020 04:32:32 -0800 (PST) In-Reply-To: <20200205171306.GP14879@hirez.programming.kicks-ass.net> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Peter Zijlstra Cc: Hajime Tazaki , linux-um , Akira Moroo , linux-kernel-library , linux-arch , Will Deacon , Boqun Feng On Wed, Feb 5, 2020 at 7:13 PM Peter Zijlstra wrote: > > On Wed, Feb 05, 2020 at 04:00:41PM +0200, Octavian Purdila wrote: > > On Wed, Feb 5, 2020 at 2:49 PM Peter Zijlstra wrote: > > > > > > On Wed, Feb 05, 2020 at 02:24:38PM +0200, Octavian Purdila wrote: > > > > I was not aware that not allowing GENERIC_ATOMIC64 was intentional. I > > > > > > It might not have been, but presented with this patch, I feel like it > > > should've been :-) > > > > > > > understand your point that a 64 bit architecture that can't handle 64 > > > > bit atomic operation is broken. > > > > > > (sadly they actually exist, I shall name no names) > > > > > > > One way to deal with this in LKL would be to use GCC atomic builtins > > > > or if that doesn't work expose them as host operations. This would > > > > keep LKL as a meta-arch that can run on multiple physical > > > > architectures. I'll give it a try. > > > > > > What is this LKL you speak of and how does it do the 32bit atomics? > > > > > > > LKL is a build of the Linux kernel as a library that can run in many > > environments including multiple architectures and OSes [1] > > Thanks, I'll put it on the to-read list. > > > For 32bit atomics LKL also uses the asm-generic implementation. It is > > very similar with generic 64bit atomic implementation and it is used > > by multiple 32bit arches. I think this was my original reasoning for > > this patch and not going with C11 atomics. > > Uh no, asm-generic/atomic.h is radically different from lib/atomic64.c. > > asm-generic/atomic.h builds all required atomic operations from > cmpxchg() (loops), while lib/atomic64.c builds 64bit atomics by using a > hashed set of spinlocks. > > The asm-generic stuff gives you real atomic ops, albeit sub-optimal, > lib/atomic64.c gives you a turd. Ah, yes, I overlooked that. (I think that they are equivalent for LKL because it is a non-SMP arch only at this moment, but I agree that the better approach is to have a proper implementation in LKL) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x241.google.com ([2a00:1450:4864:20::241]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j02oE-0007kA-Cp for linux-um@lists.infradead.org; Fri, 07 Feb 2020 12:32:35 +0000 Received: by mail-lj1-x241.google.com with SMTP id q8so1932138ljj.11 for ; Fri, 07 Feb 2020 04:32:33 -0800 (PST) MIME-Version: 1.0 References: <39e1313ff3cf3eab6ceb5ae322fcd3e5d4432167.1580882335.git.thehajime@gmail.com> <20200205093454.GG14879@hirez.programming.kicks-ass.net> <20200205124908.GL14879@hirez.programming.kicks-ass.net> <20200205171306.GP14879@hirez.programming.kicks-ass.net> In-Reply-To: <20200205171306.GP14879@hirez.programming.kicks-ass.net> From: Octavian Purdila Date: Fri, 7 Feb 2020 14:32:20 +0200 Message-ID: Subject: Re: [RFC v3 01/26] asm-generic: atomic64: allow using generic atomic64 on 64bit platforms List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Peter Zijlstra Cc: linux-arch , Boqun Feng , linux-um , Akira Moroo , linux-kernel-library , Will Deacon , Hajime Tazaki On Wed, Feb 5, 2020 at 7:13 PM Peter Zijlstra wrote: > > On Wed, Feb 05, 2020 at 04:00:41PM +0200, Octavian Purdila wrote: > > On Wed, Feb 5, 2020 at 2:49 PM Peter Zijlstra wrote: > > > > > > On Wed, Feb 05, 2020 at 02:24:38PM +0200, Octavian Purdila wrote: > > > > I was not aware that not allowing GENERIC_ATOMIC64 was intentional. I > > > > > > It might not have been, but presented with this patch, I feel like it > > > should've been :-) > > > > > > > understand your point that a 64 bit architecture that can't handle 64 > > > > bit atomic operation is broken. > > > > > > (sadly they actually exist, I shall name no names) > > > > > > > One way to deal with this in LKL would be to use GCC atomic builtins > > > > or if that doesn't work expose them as host operations. This would > > > > keep LKL as a meta-arch that can run on multiple physical > > > > architectures. I'll give it a try. > > > > > > What is this LKL you speak of and how does it do the 32bit atomics? > > > > > > > LKL is a build of the Linux kernel as a library that can run in many > > environments including multiple architectures and OSes [1] > > Thanks, I'll put it on the to-read list. > > > For 32bit atomics LKL also uses the asm-generic implementation. It is > > very similar with generic 64bit atomic implementation and it is used > > by multiple 32bit arches. I think this was my original reasoning for > > this patch and not going with C11 atomics. > > Uh no, asm-generic/atomic.h is radically different from lib/atomic64.c. > > asm-generic/atomic.h builds all required atomic operations from > cmpxchg() (loops), while lib/atomic64.c builds 64bit atomics by using a > hashed set of spinlocks. > > The asm-generic stuff gives you real atomic ops, albeit sub-optimal, > lib/atomic64.c gives you a turd. Ah, yes, I overlooked that. (I think that they are equivalent for LKL because it is a non-SMP arch only at this moment, but I agree that the better approach is to have a proper implementation in LKL) _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um