From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033034AbdEXVK4 (ORCPT ); Wed, 24 May 2017 17:10:56 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:35802 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1032657AbdEXVKw (ORCPT ); Wed, 24 May 2017 17:10:52 -0400 Date: Wed, 24 May 2017 14:10:48 -0700 From: "Paul E. McKenney" To: Thomas Gleixner Cc: LKML , Peter Zijlstra , Ingo Molnar , Steven Rostedt , Sebastian Siewior , Mathieu Desnoyers , Masami Hiramatsu Subject: Re: [patch V3 23/32] perf/tracing/cpuhotplug: Fix locking order Reply-To: paulmck@linux.vnet.ibm.com References: <20170524081511.203800767@linutronix.de> <20170524081548.930941109@linutronix.de> <20170524183018.GH3956@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: 17052421-0036-0000-0000-00000211C563 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007112; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000212; SDB=6.00865124; UDB=6.00429536; IPR=6.00644904; BA=6.00005372; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015570; XFM=3.00000015; UTC=2017-05-24 21:10:50 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17052421-0037-0000-0000-000040764BA7 Message-Id: <20170524211048.GK3956@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-24_13:,, 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-1703280000 definitions=main-1705240108 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 24, 2017 at 08:47:00PM +0200, Thomas Gleixner wrote: > On Wed, 24 May 2017, Paul E. McKenney wrote: > > > @@ -8920,7 +8912,7 @@ perf_event_mux_interval_ms_store(struct > > > pmu->hrtimer_interval_ms = timer; > > > > > > /* update all cpuctx for this PMU */ > > > - get_online_cpus(); > > > + cpus_read_lock(); > > > > OK, I'll bite... > > > > Why is this piece using cpus_read_lock() instead of pmus_lock? > > > > My guess is for the benefit of the cpu_function_call() below, but if > > the code instead cycled through the perf_online_mask, wouldn't any > > CPU selected be guaranteed to be online? > > Indeed. > > > Or is there some reason that it would be necessary to specially handle > > CPUs that perf does not consider to be active, but that are still at > > least partway online? > > I have to delegate that question to Peter :) Another reason might be a desire to avoid contention on pmus_lock, if this function is called often. If that is the case, I cannot resist suggesting percpu_rw_sem. ;-) Thanx, Paul