From: "Doug Smythies" <dsmythies@telus.net>
To: 'Philippe Longepe' <philippe.longepe@linux.intel.com>
Cc: srinivas.pandruvada@linux.intel.com,
'Philippe Longepe' <philippe.longepe@intel.com>,
'Stephane Gasparini' <stephane.gasparini@intel.com>,
linux-pm@vger.kernel.org
Subject: RE: [PATCH v1 5/5] cpufreq: intel_pstate: try load instead of busy_scaled
Date: Mon, 23 Nov 2015 17:33:55 -0800 [thread overview]
Message-ID: <001d01d12658$2f9e5c20$8edb1460$@net> (raw)
In-Reply-To: <1448284006-13596-11-git-send-email-philippe.longepe@linux.intel.com>
On 2015.11.23 05:07 Philippe Longepe wrote:
> The time spent in iowait is converted into cycles at max freq,
> so it increases the load during IOs.
...
> + cummulative_iowait = get_cpu_iowait_time_us(cpu->cpu, &now);
...
Did you consider to use get_cpu_idle_time_us(cpu_num, NULL) instead?
Why? Because it doesn't include iowait time, and thus just subtract
it from the kernel time to get the load, including iowait.
Crudely, below is what I have been trying for a month now (which also
makes the is mpref / tsc allowed or not discussion moot, because it
isn't used). Note, it can include iowait or not, you can observe by the
commented out lines (I have been testing both methods):
@@ -726,21 +737,32 @@ static inline void intel_pstate_sample(struct cpudata *cpu)
tsc = rdtsc();
local_irq_restore(flags);
+ time = ktime_get();
+ idle_us = get_cpu_idle_time_us(cpu_num, NULL);
+// io_wait_us = get_cpu_iowait_time_us(cpu_num, NULL);
+ if (idle_us == -1ULL) {
+ /* !NO_HZ so we can rely on cpustat.idle */
+ idle = kcpustat_cpu(cpu_num).cpustat[CPUTIME_IDLE];
+// io_wait = kcpustat_cpu(cpu_num).cpustat[CPUTIME_IOWAIT];
+ idle_us = cputime_to_usecs(idle);
+// io_wait_us = cputime_to_usecs(io_wait);
+ }
...
+ cpu->sample.duration_us = ktime_us_delta(time, cpu->prev_time);
+ cpu->sample.idle_us = idle_us - cpu->prev_idle_us;
+// cpu->sample.io_wait_us = io_wait_us - cpu->prev_io_wait_us;
And then the load calculation becomes (I use units of tenths of a percent in my stuff):
- core_pct = int_tofp(sample->mperf) * int_tofp(1000);
- core_pct = div64_u64(core_pct, int_tofp(sample->tsc));
+// core_pct = sample->duration_us - sample->idle_us - sample->io_wait_us;
+ core_pct = sample->duration_us - sample->idle_us;
+ if (core_pct < 0) core_pct = 0;
+ core_pct = int_tofp(core_pct) * int_tofp(1000);
+ core_pct = div64_u64(core_pct, int_tofp(sample->duration_us));
In the above notice the special NO_HZ case. I don't this area well,
but I was of the understanding that the NO_HZ case requires special code.
(see also: fs/proc/stat.c, which is where I stole this stuff.) Note
that I haven't actually tested NO_HZ mode yet.
... Doug
next prev parent reply other threads:[~2015-11-24 1:33 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 13:06 [PATCH v1 0/5] intel_pstate: Use the cpu load first on Atom only Philippe Longepe
2015-11-23 13:06 ` Philippe Longepe
2015-11-23 13:06 ` [PATCH v1 1/5] cpufreq: intel_pstate: change function name for calculation for busy Philippe Longepe
2015-11-23 13:06 ` [PATCH " Philippe Longepe
2015-11-23 13:06 ` [PATCH v1 2/5] cpufreq: intel_pstate: Rename current busy calculation function Philippe Longepe
2015-11-23 13:06 ` Philippe Longepe
2015-11-23 13:06 ` [PATCH v1 3/5] cpufreq: intel_pstate: account for non C0 time Philippe Longepe
2015-11-23 13:06 ` Philippe Longepe
2015-11-23 13:06 ` [PATCH v1 4/5] cpufreq: intel_pstate: configurable busy calculation Philippe Longepe
2015-11-23 13:06 ` Philippe Longepe
2015-11-23 13:06 ` [PATCH v1 5/5] cpufreq: intel_pstate: try load instead of busy_scaled Philippe Longepe
2015-11-23 16:10 ` Doug Smythies
2015-11-23 16:26 ` Philippe Longepe
2015-11-24 1:33 ` Doug Smythies [this message]
2015-11-23 13:06 ` Philippe Longepe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='001d01d12658$2f9e5c20$8edb1460$@net' \
--to=dsmythies@telus.net \
--cc=linux-pm@vger.kernel.org \
--cc=philippe.longepe@intel.com \
--cc=philippe.longepe@linux.intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=stephane.gasparini@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.