From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755066AbdGSOsh (ORCPT ); Wed, 19 Jul 2017 10:48:37 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:40960 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754788AbdGSOse (ORCPT ); Wed, 19 Jul 2017 10:48:34 -0400 Date: Wed, 19 Jul 2017 07:48:27 -0700 From: "Paul E. McKenney" To: "Li, Aubrey" Cc: Thomas Gleixner , Andi Kleen , Peter Zijlstra , Frederic Weisbecker , Christoph Lameter , Aubrey Li , len.brown@intel.com, rjw@rjwysocki.net, tim.c.chen@linux.intel.com, arjan@linux.intel.com, yang.zhang.wz@gmail.com, x86@kernel.org, linux-kernel@vger.kernel.org, daniel.lezcano@linaro.org Subject: Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Reply-To: paulmck@linux.vnet.ibm.com References: <20170714155356.GH3441@tassilo.jf.intel.com> <20170714160648.tg2u6eo2id6gmnjz@hirez.programming.kicks-ass.net> <20170714162619.GJ3441@tassilo.jf.intel.com> <20170717192309.ubn5muvc3u7htuaw@hirez.programming.kicks-ass.net> <34371ef8-b8bc-d2bf-93de-3fccd6beb032@linux.intel.com> <20170718044521.GO3441@tassilo.jf.intel.com> <20170718152014.GB3981@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17071914-0052-0000-0000-0000024296A8 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007387; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00889843; UDB=6.00444520; IPR=6.00670015; BA=6.00005479; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016276; XFM=3.00000015; UTC=2017-07-19 14:48:30 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17071914-0053-0000-0000-0000516161F2 Message-Id: <20170719144827.GB3730@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-19_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707190242 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 19, 2017 at 01:44:06PM +0800, Li, Aubrey wrote: > On 2017/7/18 23:20, Paul E. McKenney wrote: > > >> 2) for rcu idle enter/exit, I measured the details which Paul provided, and > >> the result matches with what I have measured before, nothing notable found. > >> But it still makes more sense if we can make rcu idle enter/exit hooked with > >> tick off. (it's possible other workloads behave differently) > > > > Again, assuming that RCU is informed of CPUs in the kernel, regardless > > of whether or not the tick is on that that point in time. > > > Yeah, I see, no problem for a normal idle. > > But for a short idle, we want to return to the task ASAP. Even though RCU cost > is not notable, it would still be better for me if we can save some cycles in > idle entry and idle exit. > > Do we have any problem if we skip RCU idle enter/exit under a fast idle scenario? > My understanding is, if tick is not stopped, then we don't need inform RCU in > idle path, it can be informed in irq exit. Indeed, the problem arises when the tick is stopped. Thanx, Paul