Received: by 10.223.176.46 with SMTP id f43csp281931wra; Thu, 18 Jan 2018 17:23:39 -0800 (PST) X-Google-Smtp-Source: ACJfBosBvMinHWOUIxh+XJwVjn74NjmO99zi9/7M7knETNuluKD3EoTos7hCZ82Mt3eHoK0X7vbS X-Received: by 10.98.9.67 with SMTP id e64mr19201663pfd.230.1516325019586; Thu, 18 Jan 2018 17:23:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516325019; cv=none; d=google.com; s=arc-20160816; b=BNAOpyDphpMqB1jjC9H0UJunTa0tT4H0TYEVWpVEhBCWRl8aGftvEwHsHdIAGKo31p 4UPOTyY4D4XDcky7vX2oi0uEbJNlBwyDeWTC5/V4uNWvS6HjDO0Q6ALNOdjiluI3h4F5 1RU2KLrdFpP7ropmrWaQ42DWi8oeBg9ynZzdQwDjCvQ9UmmUKQrLMc3K1J+Vft6VNZCG L9IYSA5ThESIYpXWMKhFpR/7vVdH5/3i8fSfE3q+4swEfbtTVLOFIAz5oTl+yVu64OEO OvU0OB2HZavOt96bdduluegyYRdKLTlBCdcfgsbQ1m1sx7Tmrqhx+zPwvO+0mVSLR8iB DIZQ== 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:arc-authentication-results; bh=PFMg8Ldtz9ZGokGcgYOcQX63+VNDzJX/gM0Fm4lBD78=; b=0/2IjCnt8hR4qcQEotMhoE3Hj0yd2aR/elaTYYhazYKlilcYUanuccPzSTnlLN7qxw Rb1HdwT/n3qqCOvjVtOsoK4fv00CVlrbYxsGfij9mvL4itSP7fhNc1NsB1NgxBCfaeml yq6BTtoCpGiYHmUNand1QJ01E4o4QLrurPToVCZZLM2WewMNOhSxUML4Tv0Dmc3z7OoH ZR2bt5VTKX+ULuOQbMTrhPC014CMTgsrXYACCj2P4YtnDQ8R+TrsTKjbdVSvVUP8YNj7 9xKyh6O0WlnoGzrUfSa3faSvB+SokY/WasooTSIbf6V5GlqyUJk3HsgqyCiB94xp79Mw L9cA== 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 126si8061567pfe.67.2018.01.18.17.23.24; Thu, 18 Jan 2018 17:23:39 -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 S1755245AbeASBW6 (ORCPT + 99 others); Thu, 18 Jan 2018 20:22:58 -0500 Received: from mga07.intel.com ([134.134.136.100]:33570 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750784AbeASBWy (ORCPT ); Thu, 18 Jan 2018 20:22:54 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2018 17:22:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,379,1511856000"; d="scan'208";a="20925504" Received: from sofia.sh.intel.com (HELO sofia) ([10.239.147.120]) by FMSMGA003.fm.intel.com with ESMTP; 18 Jan 2018 17:22:52 -0800 Date: Fri, 19 Jan 2018 09:21:59 +0800 From: "Liu, Changcheng" To: "Paul E. McKenney" Cc: Lai Jiangshan , Mathieu Desnoyers , linux-kernel@vger.kernel.org Subject: Re: [PATCH] rcu: refine structure rcu_node field for rcu boost Message-ID: <20180119012159.GA114965@sofia> References: <20180118103342.GA114176@sofia> <20180118173825.GG9671@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180118173825.GG9671@linux.vnet.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Paul, This patch is optional. 1. It's true that the added #ifdef in rcu_read_unlock_special is a bad breaker. The patch follows the current code e.g. CONFIG_PROVE_RCU 2. Haven't evaluated the performance in system. Studying RCU and found that boost feature field is allocated in in the rcu_node structure even rcu boost isn't enabled. B.R. Changcheng On 09:38 Thu 18 Jan, Paul E. McKenney wrote: > On Thu, Jan 18, 2018 at 06:33:43PM +0800, Liu, Changcheng wrote: > > Do not allocate space for rcu boost field when > > RCU BOOST is not configured. > > > > Signed-off-by: Liu Changcheng > > The added #ifdef in rcu_read_unlock_special() is a deal-breaker. > Just out of curiosity, is this decrease in storage measurable at > the system level? > > Thanx, Paul > > > diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h > > index 46a5d19..88f087e 100644 > > --- a/kernel/rcu/tree.h > > +++ b/kernel/rcu/tree.h > > @@ -129,6 +129,7 @@ struct rcu_node { > > /* if there is no such task. If there */ > > /* is no current expedited grace period, */ > > /* then there can cannot be any such task. */ > > +#ifdef CONFIG_RCU_BOOST > > struct list_head *boost_tasks; > > /* Pointer to first task that needs to be */ > > /* priority boosted, or NULL if no priority */ > > @@ -153,6 +154,8 @@ struct rcu_node { > > /* Number of tasks boosted for expedited GP. */ > > unsigned long n_normal_boosts; > > /* Number of tasks boosted for normal GP. */ > > +#endif/* #ifdef CONFIG_RCU_BOOST*/ > > + > > #ifdef CONFIG_RCU_NOCB_CPU > > struct swait_queue_head nocb_gp_wq[2]; > > /* Place for rcu_nocb_kthread() to wait GP. */ > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > > index db85ca3..fee0b1e 100644 > > --- a/kernel/rcu/tree_plugin.h > > +++ b/kernel/rcu/tree_plugin.h > > @@ -506,8 +506,10 @@ void rcu_read_unlock_special(struct task_struct *t) > > if (IS_ENABLED(CONFIG_RCU_BOOST)) { > > /* Snapshot ->boost_mtx ownership w/rnp->lock held. */ > > drop_boost_mutex = rt_mutex_owner(&rnp->boost_mtx) == t; > > +#ifdef CONFIG_RCU_BOOST > > if (&t->rcu_node_entry == rnp->boost_tasks) > > rnp->boost_tasks = np; > > +#endif > > } > > > > /* > > -- > > 2.7.4 > > > >