Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753024AbbHaUog (ORCPT ); Mon, 31 Aug 2015 16:44:36 -0400 Received: from casper.infradead.org ([85.118.1.10]:42761 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752207AbbHaUof (ORCPT ); Mon, 31 Aug 2015 16:44:35 -0400 Date: Mon, 31 Aug 2015 22:44:26 +0200 From: Peter Zijlstra To: Guenter Roeck Cc: Borislav Petkov , Ingo Molnar , Huang Rui , Borislav Petkov , Jean Delvare , Andy Lutomirski , Andreas Herrmann , Thomas Gleixner , "Rafael J. Wysocki" , Len Brown , John Stultz , =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org, x86@kernel.org, Andreas Herrmann , Aravind Gopalakrishnan , Fengguang Wu , Aaron Lu , Tony Li Subject: Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit Message-ID: <20150831204426.GI16853@twins.programming.kicks-ass.net> References: <1440662866-28716-1-git-send-email-ray.huang@amd.com> <1440662866-28716-10-git-send-email-ray.huang@amd.com> <20150828064814.GB20153@nazgul.tnic> <20150828080418.GB13309@gmail.com> <20150829091914.GA8878@gmail.com> <20150830155322.GA26370@nazgul.tnic> <20150831083821.GE16853@twins.programming.kicks-ass.net> <20150831160622.GA29830@nazgul.tnic> <55E47E88.7080202@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55E47E88.7080202@roeck-us.net> 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: 2043 Lines: 49 On Mon, Aug 31, 2015 at 09:19:20AM -0700, Guenter Roeck wrote: > On 08/31/2015 09:06 AM, Borislav Petkov wrote: > >That's a good point - I missed that during previous review. Rui, please > >put the rdmsrl_safe_on_cpu() accesses in a separate function which you > >run on a particular CPU, for your next version. > > > ... and maybe work with Peter to address the other hotplug related issues. > > It might also be worthwhile thinking about per-CU attributes, if that > provides any value (Peter's comments suggested that this might be the case). Yeah, so it would allow measuring the power of a subset of compute units. Typically only useful if you've partitioned your workload. But since the hardware trivially supports it, its a waste to not expose it. (Note that its not per-cpu, its per compute unit. What we do with perf is export a cpumask) My biggest problem is that all this is user readable and unthrottled. It basically allows DoS (perf does not typically allow user access to CPU wide resources). Imagine joe user doing: for ((i=0; i<1000; i++)); do (while :; do cat /sys/foo/file > /dev/null ; done) & done Even when contained to a subset of CPUs, that will cause an IPI storm on all (/2) CPUs, even if you've tried really hard to keep users away from some of them (see the above partitioning) because you're running some important RT workload or whatnot. As to hotplug, if you unplug any of the even numbered CPUs the whole thing bails and returns 0, even if the corresponding odd CPU of the compute unit it still online and perfectly capable of accessing the MSR. As to relying on CPU numbering, maybe I should go write an APICID -> cpu number randomizer, just for kicks to see what else fails. We have topology information and cpumasks aplenty for things like this. -- 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/