Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp1872357ybm; Thu, 23 May 2019 08:00:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqyijYe0H9j8/YiFQmgN/7vC/zweK1seA/qUlSULwoFievWbArE4gdcJ34zVTerfeuMnbFJL X-Received: by 2002:a63:2325:: with SMTP id j37mr97266145pgj.137.1558623607855; Thu, 23 May 2019 08:00:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558623607; cv=none; d=google.com; s=arc-20160816; b=fa8JIxoUX1TnupYvf+cK6RLCWDriA3oe6sDh8ApqPwR6FHMCQh+/QucANl0JBMdyvq WKVcmHkF/TkTIM14FiJg0C7bZDIsTMSgm/e4CPEOPJuDkDE3Go2PsYDq7LCX+JAaWUMz y1xnue5+qBvzCZMtcqqqdNVQtgO3uue4h4KVvhhzMKP3NjiJy5ppeEb7gfFVSPdYa4gy 3u08+Ghc1NAy//eFSolqft5gnR2JAHX9Gk/UT0K4th6xxCMhj6Zn2mo6rywG1t7WUdTh hw2eWo4RnqYpmeHb3I6qWxTGijE6cwMeARY2tTLT3+XaWPEz2sEnDAvZMK5lQWhwCiwi jVpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=gDcgwX40YZDtdaERbR4QP7EbpC7xeSEjLByAkZGOE8M=; b=g1e8Jv2bygzR+1pVINeuYm3eeUfYgOjNtKD26S7I2dic48eMRbCXnvQVEIBjn7DJwF 6uG57tlDITm4a+Ked3g9M1J7mhd4CxI//EiE+EQPE293hyN95159waBovGk8l5mPIZTN +FrXFSioNbak9HjyorNk3FYuP9xtFREw1MDsmGy5PD1b7AT5x+5vRUf7h1pYlZf0z0cA ognfbcIGKFozMXqqOh6Dm8SVpsqsdnhDfkciAFtyyHL2tT1OuKIHQpsbP0qu/3sbHjxE 6VEbDLCdhvYLl0pg0J2OvYOYFV/6cjDTjOG7DCNoQZyBZAyBbJZrbeOdSTdVfSZb3hU6 n86g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 92si25328335plw.163.2019.05.23.07.59.51; Thu, 23 May 2019 08:00:07 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730792AbfEWO6p (ORCPT + 99 others); Thu, 23 May 2019 10:58:45 -0400 Received: from foss.arm.com ([217.140.101.70]:48230 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730709AbfEWO6p (ORCPT ); Thu, 23 May 2019 10:58:45 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 78F4E80D; Thu, 23 May 2019 07:58:44 -0700 (PDT) Received: from fuggles.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6134F3F690; Thu, 23 May 2019 07:58:42 -0700 (PDT) Date: Thu, 23 May 2019 15:58:39 +0100 From: Will Deacon To: Linus Torvalds Cc: Waiman Long , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Borislav Petkov , "H. Peter Anvin" , Linux List Kernel Mailing , the arch/x86 maintainers , Davidlohr Bueso , Tim Chen , huang ying Subject: Re: [PATCH] locking/lock_events: Use this_cpu_add() when necessary Message-ID: <20190523145839.GB31896@fuggles.cambridge.arm.com> References: <20190522153953.30341-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.1+86 (6f28e57d73f2) () Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 22, 2019 at 12:54:13PM -0700, Linus Torvalds wrote: > On Wed, May 22, 2019 at 8:40 AM Waiman Long wrote: > > > > +#if defined(CONFIG_PREEMPT) && \ > > + (defined(CONFIG_DEBUG_PREEMPT) || !defined(CONFIG_X86)) > > +#define lockevent_percpu_inc(x) this_cpu_inc(x) > > +#define lockevent_percpu_add(x, v) this_cpu_add(x, v) > > Why that CONFIG_X86 special case? > > On x86, the regular non-underscore versionm is perfectly fine, and the > underscore is no faster or simpler. > > So just make it be > > #if defined(CONFIG_PREEMPT) > .. non-underscore versions.. > #else > .. underscore versions .. > #endif > > and realize that x86 simply doesn't _care_. On x86, it will be one > single instruction regardless. > > Non-x86 may prefer the underscore versions for the non-preempt case. To be honest, given this depends on LOCK_EVENT_COUNTS, I'd be inclined to keep things simple and drop the underscore versions entirely. Saves having to worry about things like "could I take an interrupt during the add?". Will