Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp3833460ybn; Fri, 27 Sep 2019 12:03:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqwPzJZEIZG5Jep9gAA1qO4nE7PwpiYCwUhY4OA7fT6icC/MvxTSrDKtka+S6rA76ABj/vwz X-Received: by 2002:a50:a41c:: with SMTP id u28mr6286568edb.185.1569611013132; Fri, 27 Sep 2019 12:03:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569611013; cv=none; d=google.com; s=arc-20160816; b=j5beXYjG4WXJSOuQHsjsR6zMUbwRsa5BYR68492/xgzVMdYqu0JWBu5p2HK2Y0U6d/ P3Iuwztd2ra1roW2ZbEqBTk2gETzWAuw0T73pzx2elGZ+eWbXIibikMQAxjD/wPZUDUm o/TwMb1YmotNOLqUeySeZK1xlzWSKs9VItmvYaO0m1yj/fioS//RrNYwyFJP5N+EfOIC a/IKCOBP/ihjkC/8Oe6CZuF5Mgs6kF9i1QtL/sMEYMr7114pV5VW9kbSzhTSPSjJcN+Q Nib28rnjtFkObA2sjZHOI6cGj/PotkXRTA1etfBLmKHjjVrvT3HCK8VDiVZp99oM8imT fz7g== 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:dkim-signature; bh=N4v7wCjoSpYFMsj3nEo+NdEMz+C8ZBgVSo7XRwBqt8E=; b=WX3D5LWKwf7D6APYH+JSj/qhUmMycfl8nxEIL3BEgs3sZ5mr8HVKS1+PqNBxvBTxLU nYXjxQqzXZ7Vd6yuBzbzQD1Lb87MfK3KOn+oGWfe+/ay5Ul+31FKCeiaK6lVdL2LP5Qs JiSOeLFC7mh9Vhxv5qUfG48dPaLUYwrZOgUMwbEgMRW617NoJny9tPxG72+W5zVwWvq7 mOTNMKcYvh1Gm7AD3nQzOUYnS1Kcwt/1c7SAkQgnxt9CzwrneoUjWhHaUvYWMV19hqe+ TKgqeLxKNGWxRW4xJdO2GFiG9wtdp7FKQCg4wV42zdGlKNszthXg4glVt8VgAGQZRYFe nvCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lbk0CZYN; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g5si3296758eje.339.2019.09.27.12.03.08; Fri, 27 Sep 2019 12:03: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; dkim=pass header.i=@kernel.org header.s=default header.b=lbk0CZYN; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728188AbfI0S7z (ORCPT + 99 others); Fri, 27 Sep 2019 14:59:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:58528 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728171AbfI0S7y (ORCPT ); Fri, 27 Sep 2019 14:59:54 -0400 Received: from [192.168.1.112] (c-24-9-64-241.hsd1.co.comcast.net [24.9.64.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EA403207FF; Fri, 27 Sep 2019 18:59:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569610793; bh=E73g80IzW6M1EitSeL0eIccYNXP+iG5cDrk7F+CAOI4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lbk0CZYN7l4OBvnl8OAlF/JVsFiAJJq3vwVUD0lLmU/yX6kt3w+k1OWLrXJHWINsf 2geCKyLrIXXlCvJYibE1NgOXKyQ5AAk37lHdNwsXf6eEQJwTKA+9FYoPHekUNzxJZL RJDe79uBC2uqbPQqBCrp+bjjQAy16oa1v2OhntUA= Subject: Re: [PATCH 1/2] Modify cpupower to schedule itself on cores it is reading MSRs from To: "Natarajan, Janakarajan" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Cc: Thomas Renninger , Pu Wen , Borislav Petkov , Allison Randal , Thomas Gleixner , Kate Stewart , Greg Kroah-Hartman , Richard Fontana , shuah References: <20190918163445.129103-1-Janakarajan.Natarajan@amd.com> From: shuah Message-ID: Date: Fri, 27 Sep 2019 12:59:52 -0600 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: <20190918163445.129103-1-Janakarajan.Natarajan@amd.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/18/19 10:34 AM, Natarajan, Janakarajan wrote: > Modify cpupower to schedule itself on each of the cpus in the system and > then get the APERF/MPERF register values. > > This is advantageous because an IPI is not generated when a read_msr() is > executed on the local logical CPU thereby reducing the chance of having > APERF and MPERF being out of sync. Somehow this doesn't read right. Is this that you are trying to avoid APERF and MPERF being out of sync with this change? This description is rather confusing. > > Signed-off-by: Janakarajan Natarajan > --- > .../utils/idle_monitor/mperf_monitor.c | 38 ++++++++++++++----- > 1 file changed, 28 insertions(+), 10 deletions(-) > > diff --git a/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c b/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c > index 44806a6dae11..8b072e39c897 100644 > --- a/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c > +++ b/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > > #include > > @@ -86,15 +87,33 @@ static int mperf_get_tsc(unsigned long long *tsc) > return ret; > } > > +static int get_aperf_mperf(int cpu, unsigned long long *aval, > + unsigned long long *mval) > +{ > + cpu_set_t set; > + int ret; > + > + CPU_ZERO(&set); > + CPU_SET(cpu, &set); > + if (sched_setaffinity(getpid(), sizeof(set), &set) == -1) { > + dprint("Could not migrate to cpu: %d\n", cpu); > + return 1; > + } > + > + ret = read_msr(cpu, MSR_APERF, aval); > + ret |= read_msr(cpu, MSR_MPERF, mval); > + > + return ret; > +} > + > static int mperf_init_stats(unsigned int cpu) > { > - unsigned long long val; > + unsigned long long aval, mval; > int ret; > > - ret = read_msr(cpu, MSR_APERF, &val); > - aperf_previous_count[cpu] = val; > - ret |= read_msr(cpu, MSR_MPERF, &val); > - mperf_previous_count[cpu] = val; > + ret = get_aperf_mperf(cpu, &aval, &mval); get_aperf_mperf() could return error right? It returns 1 when sched_setaffinity() fails. Shouldn't the return value checked, instead of using aval and mval? > + aperf_previous_count[cpu] = aval; > + mperf_previous_count[cpu] = mval; > is_valid[cpu] = !ret; > > return 0; > @@ -102,13 +121,12 @@ static int mperf_init_stats(unsigned int cpu) > > static int mperf_measure_stats(unsigned int cpu) > { > - unsigned long long val; > + unsigned long long aval, mval; > int ret; > > - ret = read_msr(cpu, MSR_APERF, &val); > - aperf_current_count[cpu] = val; > - ret |= read_msr(cpu, MSR_MPERF, &val); > - mperf_current_count[cpu] = val; > + ret = get_aperf_mperf(cpu, &aval, &mval); Same comments as above here. > + aperf_current_count[cpu] = aval; > + mperf_current_count[cpu] = mval; > is_valid[cpu] = !ret; > > return 0; > thanks, -- Shuah