Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2994383imm; Sun, 13 May 2018 01:44:49 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr9PKFlOGbXe2ic6BIG0/c7EnUOWCGumG4iWdTVUbjP6VFujlF4S5egIEE3XK6j3jZXmjlr X-Received: by 2002:a17:902:369:: with SMTP id 96-v6mr5416245pld.64.1526201089335; Sun, 13 May 2018 01:44:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526201089; cv=none; d=google.com; s=arc-20160816; b=lzCE3opJv69gqd7y1sCGPi7qsmBWPw0OXKGzCJ4zVtGvYK0lDTKWfw4ccbMR7QyZXl zByYQrTXtJoU/5fz9gEmcVU7Y0IORAH2iDHRRL/sEnBrG7F5RRXw1E7Cm20cXhpTU7FG lDwMFs0uSesaEBfCLQWBCIEyilFjTqibNaFhh67TuYfOmTs/u2gNY0u9kPhRjrFhqErU 3SQihG1+pVhfwfHSf+tUSf53zm/nJkvaBo2gWi46RS94emKi/iY8wNxfOpOUZriJa2fD mpvjeWDGol4pccrcWunSnDUFrpkVcPrO0ALZSiMXBKcupaZ8PdktZXZYYSA8hO9cvHt6 qHaw== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=99OX1Y3MJNkuUdCz4nhBpujGPT3GEcoDHzj6ZwOvOvM=; b=Mi88MrAujU91IXd016xFBzDPTQsr0ZVG/q1Ovvsybp98cnNr08lX3TpW8fRwMcpE4f 5cNSN8he0SJk7rSKNf74qgMzDqhXAqK6MdwLlFaDR4/g+8n3t1/OisbTiMhJyUa5qoZR 5sk2y7UakpHMNpgSZzYisXg2bZjzkUO8z7ANKNW2fmnl9RpeUi04QnlNLlwPfJyhf40w ox8ER532iaVQkowd65SpyeQredv8glNJ8yV+i3A+U4/v4qfsQPfF4F7yWq+gbMr9LnzW CzZspHo3Qr4UAInPh6MJvEPim8cPXevRHexstMAc40o8kMRT5+KE59wroTXPMW6piB4s +2WQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a2-v6si5634035pgu.26.2018.05.13.01.44.34; Sun, 13 May 2018 01:44:49 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751654AbeEMIoX (ORCPT + 99 others); Sun, 13 May 2018 04:44:23 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:45730 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750862AbeEMIoV (ORCPT ); Sun, 13 May 2018 04:44:21 -0400 Received: from 79.184.255.167.ipv4.supernova.orange.pl (79.184.255.167) (HELO aspire.rjw.lan) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83) id aa8cacadb24702f3; Sun, 13 May 2018 10:44:20 +0200 From: "Rafael J. Wysocki" To: Doug Smythies , srinivas.pandruvada@linux.intel.com Cc: dsmythies@telus.net, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: Re: [PATCH V5] cpufreq: intel_pstate: allow trace in passive mode Date: Sun, 13 May 2018 10:43:51 +0200 Message-ID: <3708753.N4DSO893cq@aspire.rjw.lan> In-Reply-To: <1525328567-23747-1-git-send-email-dsmythies@telus.net> References: <1525328567-23747-1-git-send-email-dsmythies@telus.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, May 3, 2018 8:22:47 AM CEST Doug Smythies wrote: > Allow use of the trace_pstate_sample trace function > when the intel_pstate driver is in passive mode. > Since the core_busy and scaled_busy fields are not > used, and it might be desirable to know which path > through the driver was used, either intel_cpufreq_target > or intel_cpufreq_fast_switch, re-task the core_busy > field as a flag indicator. > > The user can then use the intel_pstate_tracer.py utility > to summarize and plot the trace. > > Note: The core_busy feild still goes by that name > in include/trace/events/power.h and within the > intel_pstate_tracer.py script and csv file headers, > but it is graphed as "performance", and called > core_avg_perf now in the intel_pstate driver. > > Sometimes, in passive mode, the driver is not called for > many tens or even hundreds of seconds. The user > needs to understand, and not be confused by, this limitation. > > Signed-off-by: Doug Smythies Srinivas, any comments or concerns? > > --- > > V5: Changes as per Rafael J. Wysocki feedback. > See: https://lkml.org/lkml/2018/1/7/270 > > V4: Only execute the trace specific overhead code if trace > is enabled. Suggested by Srinivas Pandruvada. > > V3: Move largely duplicate code to a subroutine. > Suggested by Rafael J. Wysocki. > > V2: prepare for resend. Rebase to current kernel, 4.15-rc3. > > --- > drivers/cpufreq/intel_pstate.c | 44 ++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 42 insertions(+), 2 deletions(-) > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index 17e566af..4a08686 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -1939,13 +1939,49 @@ static int intel_cpufreq_verify_policy(struct cpufreq_policy *policy) > return 0; > } > > +/* Use of trace in passive mode: > + * > + * In passive mode the trace core_busy field (also known as the > + * performance field, and lablelled as such on the graphs; also known as > + * core_avg_perf) is not needed and so is re-assigned to indicate if the > + * driver call was via the normal or fast switch path. Various graphs > + * output from the intel_pstate_tracer.py utility that include core_busy > + * (or performance or core_avg_perf) have a fixed y-axis from 0 to 100%, > + * so we use 10 to indicate the the normal path through the driver, and > + * 90 to indicate the fast switch path through the driver. > + * The scaled_busy field is not used, and is set to 0. > + */ > + > +#define INTEL_PSTATE_TRACE_TARGET 10 > +#define INTEL_PSTATE_TRACE_FAST_SWITCH 90 > + > +static void intel_cpufreq_trace(struct cpudata *cpu, unsigned int trace_type, int old_pstate) > +{ > + struct sample *sample; > + > + if (!trace_pstate_sample_enabled()) > + return; > + if (!intel_pstate_sample(cpu, ktime_get())) > + return; > + sample = &cpu->sample; > + trace_pstate_sample(trace_type, > + 0, > + old_pstate, > + cpu->pstate.current_pstate, > + sample->mperf, > + sample->aperf, > + sample->tsc, > + get_avg_frequency(cpu), > + fp_toint(cpu->iowait_boost * 100)); > +} > + > static int intel_cpufreq_target(struct cpufreq_policy *policy, > unsigned int target_freq, > unsigned int relation) > { > struct cpudata *cpu = all_cpu_data[policy->cpu]; > struct cpufreq_freqs freqs; > - int target_pstate; > + int target_pstate, old_pstate; > > update_turbo_state(); > > @@ -1965,12 +2001,14 @@ static int intel_cpufreq_target(struct cpufreq_policy *policy, > break; > } > target_pstate = intel_pstate_prepare_request(cpu, target_pstate); > + old_pstate = cpu->pstate.current_pstate; > if (target_pstate != cpu->pstate.current_pstate) { > cpu->pstate.current_pstate = target_pstate; > wrmsrl_on_cpu(policy->cpu, MSR_IA32_PERF_CTL, > pstate_funcs.get_val(cpu, target_pstate)); > } > freqs.new = target_pstate * cpu->pstate.scaling; > + intel_cpufreq_trace(cpu, INTEL_PSTATE_TRACE_TARGET, old_pstate); > cpufreq_freq_transition_end(policy, &freqs, false); > > return 0; > @@ -1980,13 +2018,15 @@ static unsigned int intel_cpufreq_fast_switch(struct cpufreq_policy *policy, > unsigned int target_freq) > { > struct cpudata *cpu = all_cpu_data[policy->cpu]; > - int target_pstate; > + int target_pstate, old_pstate; > > update_turbo_state(); > > target_pstate = DIV_ROUND_UP(target_freq, cpu->pstate.scaling); > target_pstate = intel_pstate_prepare_request(cpu, target_pstate); > + old_pstate = cpu->pstate.current_pstate; > intel_pstate_update_pstate(cpu, target_pstate); > + intel_cpufreq_trace(cpu, INTEL_PSTATE_TRACE_FAST_SWITCH, old_pstate); > return target_pstate * cpu->pstate.scaling; > } > >