Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp3965837ybe; Mon, 9 Sep 2019 01:55:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqwNVziFgn97XK/IVFmaFGeaoGyaXhNryz/L4JkuVo9kC/81Ge5Y5eTGHr4bLEuaeNmZKgPM X-Received: by 2002:a50:d6db:: with SMTP id l27mr23363218edj.164.1568019333436; Mon, 09 Sep 2019 01:55:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568019333; cv=none; d=google.com; s=arc-20160816; b=i1QaaaruurMvjFTvbXyAQS4H7rOFm9PXxX6Ja2PI020VcTripx3OOmvgOritlLnzjU ocOr6mYmfsFrXUX/d2OtYjfvkMa2cYyzsHLQ/hjYR8Cv9UMB84WvJrPv2BzN/g657W+t z65ctB4fp2uW58BiKhb4FbHDJvaF2hw/42SwzJbF9hLPd/igQTMLa5MAJOwMGNiWLAaS CfmjA0E4xS3wlAH2lggilo50u8DjPdTHgwXuwoNqqKZyMHRulmWXJ7sXnP+Lt7aXucI8 71lBABQ138nzaYI9SrWRjX8etOot6edqoHmCkniG9sATNqjJcsmHe5tQO0WJCspjxtNl Hd7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=pntYwHxkxFa+LIuqry51JKNW8qMqrZ/S8zSr/Dsobq8=; b=pe2vJgRKP0tSWSq8C4M6rEYOMzDs97heX5HNFsJDmeNru4dfYUEB0QLPsOoW4xX+Sf YQAqyO/NLTImRa9oiWYkVNLFQ2VtUwhG+UV+Ura8whOyMesWFJ58iJVZ2X60bwRnqhi7 iPfKglbGBWiuCqv7zSfYXf8N/WmguplYOA9FD7YL/NPlfk9LBz4rxCe2uboholWpw0ZZ OttYEsIGQGgDsNMi8tNDajs1BA0j7aKn2ujqlpEB8ORnvEizt5mFKGuRxaAAzR6yAmxA 92GnR/g8EXRq5nxSI0ONvfCOXnG+8ChWJvdtCb7y3gzI7JdJOGXDiY+b0GqiUjWZQADJ P7Ug== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q15si7013114eja.36.2019.09.09.01.55.08; Mon, 09 Sep 2019 01:55:33 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728004AbfIHJq3 (ORCPT + 99 others); Sun, 8 Sep 2019 05:46:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54620 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727984AbfIHJq2 (ORCPT ); Sun, 8 Sep 2019 05:46:28 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 82ABA302455F; Sun, 8 Sep 2019 09:46:28 +0000 (UTC) Received: from prarit.bos.redhat.com (prarit-guest.khw1.lab.eng.bos.redhat.com [10.16.200.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id CDE1860605; Sun, 8 Sep 2019 09:46:27 +0000 (UTC) Subject: Re: [PATCH 2/2] tools/power/x86/intel-speed-select: Display core count for bucket To: Andy Shevchenko , Srinivas Pandruvada Cc: Andy Shevchenko , David Arcari , Linux Kernel Mailing List , Platform Driver References: <20190905233748.6822-1-srinivas.pandruvada@linux.intel.com> <20190905233748.6822-2-srinivas.pandruvada@linux.intel.com> <780a3faf-9e44-64f4-a354-bdee39af3af5@redhat.com> <20190906134655.GU2680@smile.fi.intel.com> <6b576770a4bbe6c24ea524083dec5a16bf3c9e94.camel@linux.intel.com> From: Prarit Bhargava Message-ID: <533a8c7c-d309-9b65-d973-120ae3e9f8b4@redhat.com> Date: Sun, 8 Sep 2019 05:46:27 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Sun, 08 Sep 2019 09:46:28 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/7/19 2:18 PM, Andy Shevchenko wrote: > On Fri, Sep 6, 2019 at 10:47 PM Srinivas Pandruvada > wrote: >> >> On Fri, 2019-09-06 at 07:50 -0700, Srinivas Pandruvada wrote: >>> On Fri, 2019-09-06 at 16:46 +0300, Andy Shevchenko wrote: >>>> On Fri, Sep 06, 2019 at 05:39:54AM -0400, Prarit Bhargava wrote: >>>>> On 9/5/19 7:37 PM, Srinivas Pandruvada wrote: >>>>>> Read the bucket and core count relationship via MSR and display >>>>>> when displaying turbo ratio limits. >>>>>> + ret = isst_send_msr_command(cpu, 0x1ae, 0, >>>>>> buckets_info); >>>>> >>>>> ^^^ you can get rid of the magic number 0x1ae by doing (sorry for >>>>> the cut-and-paste) >>>>> >>>>> diff --git a/tools/power/x86/intel-speed-select/Makefile >>>>> b/tools/power/x86/intel >>>>> index 12c6939dca2a..087d802ad844 100644 >>>>> --- a/tools/power/x86/intel-speed-select/Makefile >>>>> +++ b/tools/power/x86/intel-speed-select/Makefile >>>>> @@ -15,6 +15,8 @@ endif >>>>> MAKEFLAGS += -r >>>>> >>>>> override CFLAGS += -O2 -Wall -g -D_GNU_SOURCE -I$(OUTPUT)include >>>>> +override CFLAGS += -I../../../include >>>>> +override CFLAGS += >>>>> -DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"' >>> >>> No, we can't use msr_index. >> This comment was meant for use of /dev/cpu/X/msr not msr_index. >> I didn't want to bring in dependency on msr-index.h for couple of 2 >> MSRs and the names in msr-index.h doesn't really reflect the actual >> processing, they are doing. For example MSR_TURBO_RATIO_LIMIT1 for >> 0x1ae. The definition of 0x1AE is different on cpu model 0x55 and >> beyond. >> >>> > > It seems not applicable on top of tools patch series I had applied before. > >>>> >>>> I guess it can be done in more neat way. >>>> >>>>> As I've been looking at this code I have been wondering why >>>>> didn't >>>>> you just use >>>>> the standard /dev/cpu/X/msr interface that other x86 power >>>>> utilities (turbostat, >>>>> x86_energy_perf_policy) use? Implementing msr_read() is trivial >>>>> (warning >>>>> untested and uncompiled code) >>> >>> No. We can't. The MSR interface is disabled on several distribution >>> and >>> platforms with secured boot. So some special MSRs are only allowed >>> via >>> this IOCTL interface. >>> Which distros don't have /dev/cpu/X/msr ? None of other Intel tools have this restriction (or requirement depending on your point of view). Why is intel-speed-select special that we have to jump through hoops? P. >>> Thanks, >>> Srinivas >>> >>> >>>> >>>> Actually good point! >>>> >> > >