From: Pratik Sampat <psampat@linux.ibm.com>
To: Doug Smythies <dsmythies@telus.net>, ego@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org, rafael.j.wysocki@intel.com,
peterz@infradead.org, daniel.lezcano@linaro.org,
svaidy@linux.ibm.com, pratik.sampat@in.ibm.com,
pratik.r.sampat@gmail.com
Subject: Re: [RFC 0/1] Weighted approach to gather and use history in TEO governor
Date: Sat, 29 Feb 2020 14:28:58 +0530 [thread overview]
Message-ID: <204c27ed-9993-2809-3b78-8ac8ea8c1713@linux.ibm.com> (raw)
In-Reply-To: <000001d5ed89$0b711340$225339c0$@net>
Hello Doug,
Thanks for running these numbers for me.
On 27/02/20 9:44 pm, Doug Smythies wrote:
> On 2020.02.24 21:13 Gautham R Shenoy wrote:
>
> ...
>
>> Could you also provide power measurements for the duration when the
>> system is completely idle for each of the variants of TEO governor ?
>> Is it the case that the benefits that we are seeing above are only due
>> to Wt. TEO being more conservative than TEO governor by always
>> choosing a shallower state ?
For system idle I see similar power statistics for both the TEO and the wtteo.
> For what it's worth:
>
> CPU: Intel: i7-2600K
> Kernel: 5.6-rc2 (teo) and + this patch set (wtteo)
> Note: in general, "idle" on this system is considerably more "idle" than most systems.
> Sample period: 5 minutes.
> CPU scaling driver: intel_cpufreq
> Governor: performance
> Deepest idle state: 4 (C6)
>
> teo:
> Test duration 740 minutes (12.33 hours).
> Average processor package power: 3.84 watts
> Idle state 0: 4.19 / minute
> Idle state 1: 29.26 / minute
> Idle state 2: 46.71 / minute
> Idle state 3: 7.42 / minute
> Idle state 4: 1124.55 / minute
> Total: 2.525 idle entries per cpu per second
>
> wtteo:
> Test duration 1095 minutes (18.25 hours).
> Average processor package power: 3.84 watts
> Idle state 0: 7.98 / minute
> Idle state 1: 30.49 / minute
> Idle state 2: 52.51 / minute
> Idle state 3: 8.65 / minute
> Idle state 4: 1125.33 / minute
> Total: 2.552 idle entries per cpu per second
>
> The above/below data for this test is incomplete because my program
> doesn't process it if there are not enough state entries per sample period.
> (I need to fix that for this type of test.)
>
> I have done a couple of other tests with this patch set,
> but nothing to report yet, as the differences have been minor so far.
>
> ... Doug
>
>
---
Pratik
next prev parent reply other threads:[~2020-02-29 9:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-22 7:00 Pratik Rajesh Sampat
2020-02-22 7:00 ` [RFC 1/1] " Pratik Rajesh Sampat
2020-02-25 6:18 ` Gautham R Shenoy
2020-02-29 8:58 ` Pratik Sampat
2020-02-25 5:13 ` [RFC 0/1] " Gautham R Shenoy
2020-02-27 16:14 ` Doug Smythies
2020-02-29 8:58 ` Pratik Sampat [this message]
2020-02-29 8:58 ` Pratik Sampat
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=204c27ed-9993-2809-3b78-8ac8ea8c1713@linux.ibm.com \
--to=psampat@linux.ibm.com \
--cc=daniel.lezcano@linaro.org \
--cc=dsmythies@telus.net \
--cc=ego@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pratik.r.sampat@gmail.com \
--cc=pratik.sampat@in.ibm.com \
--cc=rafael.j.wysocki@intel.com \
--cc=svaidy@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®