Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754680AbbESKvb (ORCPT ); Tue, 19 May 2015 06:51:31 -0400 Received: from casper.infradead.org ([85.118.1.10]:52029 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751532AbbESKv3 (ORCPT ); Tue, 19 May 2015 06:51:29 -0400 Date: Tue, 19 May 2015 12:51:21 +0200 From: Peter Zijlstra To: Matt Fleming Cc: Thomas Gleixner , LKML , Vikas Shivappa , x86@kernel.org, Matt Fleming , Will Auld , Kanaka Juvva Subject: Re: [patch 3/6] x86, perf, cqm: Remove pointless spinlock from state cache Message-ID: <20150519105121.GG19282@twins.programming.kicks-ass.net> References: <20150518234114.574556332@linutronix.de> <20150518235150.001006529@linutronix.de> <20150519091318.GB17401@codeblueprint.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150519091318.GB17401@codeblueprint.co.uk> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1498 Lines: 34 On Tue, May 19, 2015 at 10:13:18AM +0100, Matt Fleming wrote: > On Tue, 19 May, at 12:00:53AM, Thomas Gleixner wrote: > > struct intel_cqm_state is a strict per cpu cache of the rmid and the > > usage counter. It can never be modified from a remote cpu. > > > > The 3 functions which modify the content: start, stop and del (del > > maps to stop) are called from the perf core with interrupts disabled > > which is enough protection for the per cpu state values. > > > > Signed-off-by: Thomas Gleixner > > --- > > arch/x86/kernel/cpu/perf_event_intel_cqm.c | 17 ++++++----------- > > 1 file changed, 6 insertions(+), 11 deletions(-) > > The state locking code was taken from Peter's original patch last year, > so it would be good for him to chime in that this is safe. It's probably > just that it was necessary in Peter's patches but after I refactored > bits I forgot to rip it out. > > But yeah, from reading the code again the lock does look entirely > superfluous. I think that all stems from a point in time when it wasn't at all clear to me what the hardware looked like, but what do I know, I can't even remember last week. All the patches looked good to me, so I already queued them. I'll add your Ack on them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/