Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp3061522ybk; Mon, 18 May 2020 16:51:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwcPodOBJxplyu3qnGP1/9gXB6134ot34sD02sAUVv8oBPTv0s8KJ7l+LwydoPI7jpcAIPV X-Received: by 2002:aa7:cd69:: with SMTP id ca9mr2384535edb.370.1589845860707; Mon, 18 May 2020 16:51:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589845860; cv=none; d=google.com; s=arc-20160816; b=EyD2Xl0oVsNVh8ViYka13OKNBKMSqaqQC83Gk7ZHwy9NRN1sMGWF3DnnxIT9B3+cTC SFOvAHbs25Nc1CEYHs757uDEFCukO5RUUZwKtfrgvoOMIfbHiOyiSzHFupU9ky4Ti7G6 ksILIX3YDTwT2jLPCBTBwJHOX1IvDWA9qncmzP+MrazvitOgknz4HVau5FERg7knpsHr XUt2ai4MAZnSO7tTjjTzQ/dZxnN9XMj8oKkBCXWr5y4WE+iL34Ta0gamv5XhYhFfTDTZ 7lTLpUv2k3VjXrgUzcDOL03s8eCOOhqARIz4kPUdR9Sm+HzL+qbJHXKYfxEzWZajbmHF W3qA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Qear2Z9MWJSv6xobtZ0lLKyEiYjp+BthQ29ye9795uY=; b=Vjc1+NF8CpdObofVaHQVCGhCrXhtGNOXV+y6Bg8h8QB+Xcht3/pSISlsfuUSjsjVZm Frl8ooasZS3vTmv4pnTVpyp4pSNOXQDaejs1jF4NGcV8ALnMnQ2xRoBhFo03WeJ7yuzP VXEXolfJZvJdbtWa3/ymCNLqyyP+lJQmL1iPpVOPtsTQ3hmChMgoXAjOytsf7aqL/chC yUOy6QzJx+ff4CoU8AcLWYoKIpRm88SFeAJmcxr3S+Ear6BtY0YPd25tSpwceZKwfIhr fLJ9JBog4tywL80ehYjpzfoQBDygiQ6cCipJyl+6o63wxwaWkXzSF27M7SZ6Q15Oy8Vw 5sng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=deM17WMi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b19si7430873ejv.48.2020.05.18.16.50.38; Mon, 18 May 2020 16:51:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=deM17WMi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728295AbgERXqI (ORCPT + 99 others); Mon, 18 May 2020 19:46:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60274 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726407AbgERXqH (ORCPT ); Mon, 18 May 2020 19:46:07 -0400 Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 58B98C061A0C for ; Mon, 18 May 2020 16:46:07 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id x5so12661664ioh.6 for ; Mon, 18 May 2020 16:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qear2Z9MWJSv6xobtZ0lLKyEiYjp+BthQ29ye9795uY=; b=deM17WMiXP0CoYPaNk0pYJs43JINW49Urrf5LNJBRlsZG5RJ3SB1+aMaCZr/AklygQ /fNjFg1qadh2FFaLRArKILcpDTxiZsORp+rFx7sIKnRJD0mb8PBC5iCwsE3ImQUy2k0X eofTxRLUyx2q4tr8o8lOkrCDyf50C9jzGDLYg+erfsrL404SAWSV5TKXhf4mGUFqKp3O 0iEufgPGfKjPhCgR8Sxs6ssFHm7M81g/f+V5A/oolaC6FJRLcggtVK3JYrdI1k/p2fsv BesAtgMEXGppBUMAcNxRYgZhQhQ+iIicdIxoiRm+vZ1FUSUeFltFFqQfcEDH0q1VH4K1 flYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qear2Z9MWJSv6xobtZ0lLKyEiYjp+BthQ29ye9795uY=; b=tsZmqhygISplr6/paoIJCTkuuTUw3+MOQLF90UDWPpsqJE3c6/sLCmymzUOkGRhM+6 Uf/3ibkhYMw+Ed/E3n6entfIi/CjI8VXFZM2uDGyBTsOi3i4HZwj/aGYXGEPiUnbLOCu eI3bJl/iXsdIuaYL9s/SsNMaKjixUc7mFArynVMQGbGqPVxceVFiTQqKFjTHwJMk52Gr 2oq58GYS1mNogWJVSgy7uPjVfy/88PVJYrrJBufih94pZ5MJZxuWxO6msKUV+iKIBYi6 ooB/PfhWQt1/jDjg4B+iIAgE5xgwJKg1cX1iB2pRUMdG2aRF7TQrdXdOgMt95HbJDYiJ zDAw== X-Gm-Message-State: AOAM533UQNof0kU6wqT00zsPb11YsmNGDEy2NmjLEM2I8w9mXaq+qUw/ 8r9Nnfmgnf/qinuHIVclwm40B6Hp8AjbxBdjCQ== X-Received: by 2002:a02:c6c5:: with SMTP id r5mr17898566jan.133.1589845565837; Mon, 18 May 2020 16:46:05 -0700 (PDT) MIME-Version: 1.0 References: <20200517152916.3146539-1-brgerst@gmail.com> <20200517152916.3146539-6-brgerst@gmail.com> In-Reply-To: From: Brian Gerst Date: Mon, 18 May 2020 19:45:53 -0400 Message-ID: Subject: Re: [PATCH 5/7] x86/percpu: Clean up percpu_add_return_op() To: Nick Desaulniers Cc: LKML , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Andy Lutomirski , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 18, 2020 at 6:46 PM Nick Desaulniers wrote: > > On Sun, May 17, 2020 at 8:29 AM Brian Gerst wrote: > > > > The core percpu macros already have a switch on the data size, so the switch > > in the x86 code is redundant and produces more dead code. > > > > Also use appropriate types for the width of the instructions. This avoids > > errors when compiling with Clang. > > > > Signed-off-by: Brian Gerst > > --- > > arch/x86/include/asm/percpu.h | 51 +++++++++++------------------------ > > 1 file changed, 16 insertions(+), 35 deletions(-) > > > > diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h > > index 21c5013a681a..ac8c391a190e 100644 > > --- a/arch/x86/include/asm/percpu.h > > +++ b/arch/x86/include/asm/percpu.h > > @@ -199,34 +199,15 @@ do { \ > > /* > > * Add return operation > > */ > > -#define percpu_add_return_op(qual, var, val) \ > > +#define percpu_add_return_op(size, qual, _var, _val) \ > > ({ \ > > - typeof(var) paro_ret__ = val; \ > > - switch (sizeof(var)) { \ > > - case 1: \ > > - asm qual ("xaddb %0, "__percpu_arg(1) \ > > - : "+q" (paro_ret__), "+m" (var) \ > > - : : "memory"); \ > > - break; \ > > - case 2: \ > > - asm qual ("xaddw %0, "__percpu_arg(1) \ > > - : "+r" (paro_ret__), "+m" (var) \ > > - : : "memory"); \ > > - break; \ > > - case 4: \ > > - asm qual ("xaddl %0, "__percpu_arg(1) \ > > - : "+r" (paro_ret__), "+m" (var) \ > > - : : "memory"); \ > > - break; \ > > - case 8: \ > > - asm qual ("xaddq %0, "__percpu_arg(1) \ > > - : "+re" (paro_ret__), "+m" (var) \ > > ^ before we use the "+re" constraint for 8B input. > > > - : : "memory"); \ > > - break; \ > > - default: __bad_percpu_size(); \ > > Comment on the series as a whole. After applying the series, the > final reference to __bad_percpu_size and switch statement in > arch/x86/include/asm/percpu.h in the definition of the > percpu_stable_op() macro. If you clean that up, too, then the rest of > this file feels more consistent with your series, even if it's not a > blocker for Clang i386 support. Then you can get rid of > __bad_percpu_size, too! I haven't yet figured out what to do with percpu_stable_op(). It's x86-specific, so there isn't another switch in the core code. I think it is supposed to be similar to READ_ONCE() but for percpu variables, but I'm not 100% sure. > > - } \ > > - paro_ret__ += val; \ > > - paro_ret__; \ > > + __pcpu_type_##size paro_tmp__ = __pcpu_cast_##size(_val); \ > > + asm qual (__pcpu_op2_##size("xadd", "%[tmp]", \ > > + __percpu_arg([var])) \ > > + : [tmp] __pcpu_reg_##size("+", paro_tmp__), \ > > ^ after, for `size == 8`, we use "+r". [0] says for "e": > > 32-bit signed integer constant, or a symbolic reference known to fit > that range (for immediate operands in sign-extending x86-64 > instructions). > > I'm guessing we're restricting the input to not allow for 64b signed > integer constants? Looking at the documentation for `xadd` (ie. > "exchange and add") [1], it looks like immediates are not allowed as > operands, only registers or memory addresses. So it seems that "e" > was never necessary. It might be helpful to note that in the commit > message, should you end up sending a v2 of the series. Maybe some > folks with more x86 inline asm experience can triple check/verify? That is correct. The "e" constraint shouldn't have been there, since XADD doesn't allow immediates. I'll make that clearer in V2. -- Brian Gerst