Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp3869449ybx; Mon, 4 Nov 2019 04:14:55 -0800 (PST) X-Google-Smtp-Source: APXvYqwWHuMC4+gdytDsJiXCWeo2yjP/ZoB8n6kLZa5PDf6rIN88wv1kmLHe8JQYmzLdOLSEfy5J X-Received: by 2002:a17:906:3285:: with SMTP id 5mr22836511ejw.143.1572869695030; Mon, 04 Nov 2019 04:14:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572869695; cv=none; d=google.com; s=arc-20160816; b=ZIFWSNYQm2rzhpNnvuNX8jCMycjXCY9a9RCVK5GfTDX5B1VXO41KNkUvmODJB9uhl7 MwjSWZWdNEX+M+lwnl4SiXIFU53cB5yptsLpCfunmdVwBO3p4Tg0Fi4hbY4GGtwJkMV4 1eXWHeEoEcJI7a0yxiaE0MaONPpFDBOZgKN3yynp0a/YbqmEedqc/5z0RIW2Vuqkwq8F cMo8PK2+AdLPmfA9lFbxgzKj3LDNlNe2SUAmAx5FFq6uP+xolWBrkcfJnG02ATCaxnCP 3zEPvvzmVpjdjwAKru4L16I+nLLREBtlo6kq8kN5lP6zLdKHAQRUrg5io36Upmqk5oCy gF0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=Dara+AHooHp4lBMnbvEg33U8RePlfcNO+9S0F9LwEC0=; b=wAOMesKTajpl36Cg0rnebRqSznOEJEp9bLgT4SYep8yeRzJMHCRxD/7NSd7AVfD0oB LEkidBWe9XTBjJ+eUnSHEqcpDOHXRNUj51zpu0F1TginuGLxHHhXL6XRsguuXDU3xhYe ATayh5pLqyFohFJsyY+po6feHOu4X1EHQISJ+cH+xTKrJF6MnUU1KHVOs6f/DnpLTA2Z hTNxMXdoWfAWwvOZc36ea/PoMtFvmRItRvIb33jxBNU+uiod/BpJ8n0hMKsrl3d2wErB RlMGF0TTFV+5CqKhxkBpnTRTbYSBV7ULG1ZCcXw6QsSXRKpf3c3lfcRslZFdVrauze/k GT5g== 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 a5si11144220ejs.274.2019.11.04.04.14.30; Mon, 04 Nov 2019 04:14:55 -0800 (PST) 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 S1728481AbfKDMK4 (ORCPT + 99 others); Mon, 4 Nov 2019 07:10:56 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:37212 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726441AbfKDMKz (ORCPT ); Mon, 4 Nov 2019 07:10:55 -0500 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1iRbAx-0005Ym-MN; Mon, 04 Nov 2019 13:09:39 +0100 Date: Mon, 4 Nov 2019 13:09:39 +0100 From: Sebastian Andrzej Siewior To: Lai Jiangshan Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , x86@kernel.org, "Paul E. McKenney" , Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Joel Fernandes , Andi Kleen , Andy Lutomirski , Fenghua Yu , Kees Cook , "Rafael J. Wysocki" , Dave Hansen , Babu Moger , Rik van Riel , "Chang S. Bae" , Jann Horn , David Windsor , Elena Reshetova , Yuyang Du , Anshuman Khandual , Richard Guy Briggs , Andrew Morton , Christian Brauner , Michal Hocko , Andrea Arcangeli , Al Viro , "Dmitry V. Levin" , rcu@vger.kernel.org Subject: Re: [PATCH V2 7/7] x86,rcu: use percpu rcu_preempt_depth Message-ID: <20191104120939.5e4hdcoat2v4jxov@linutronix.de> References: <20191102124559.1135-1-laijs@linux.alibaba.com> <20191102124559.1135-8-laijs@linux.alibaba.com> <20191104092519.nukaz5qmgiskzafi@linutronix.de> <4878ccfd-7a4e-4f84-9bc3-1d477e077587@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4878ccfd-7a4e-4f84-9bc3-1d477e077587@linux.alibaba.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-11-04 19:41:20 [+0800], Lai Jiangshan wrote: > > Is there a benchmark saying how much we gain from this? > > Hello > > Maybe I can write a tight loop for testing, but I don't > think anyone will be interesting in it. > > I'm also trying to find some good real tests. I need > some suggestions here. There is rcutorture but I don't know how much of performance test this is, Paul would know. A micro benchmark is one thing. Any visible changes in userland to workloads like building a kernel or hackbench? I don't argue that incrementing a per-CPU variable is more efficient than reading a per-CPU variable, adding an offset and then incrementing it. I was just curious to see if there are any numbers on it. > > > No function call when using rcu_read_[un]lock(). > > > Single instruction for rcu_read_lock(). > > > 2 instructions for fast path of rcu_read_unlock(). > > > > I think these were not inlined due to the header requirements. > > objdump -D -S kernel/workqueue.o shows (selected fractions): That was not what I meant. To inline current rcu_read_lock() would mean to include definition for struct task_struct (and everything down the road) in the rcu headers which isn't working. > Best regards > Lai Sebastian