Hi Pratik,
V4 seems fine. Thank you.
On Mon, Apr 12, 2021 at 12:43 AM Pratik Rajesh Sampat
wrote:
>
> Changelog v3-->v4
> Based on review comments by Doug Smythies,
> 1. Parsing the thread_siblings_list for CPU topology information to
>correctly identify the cores the tes
On Fri, Apr 9, 2021 at 12:43 AM Pratik Sampat wrote:
> On 09/04/21 10:53 am, Doug Smythies wrote:
> > I tried V3 on a Intel i5-10600K processor with 6 cores and 12 CPUs.
> > The core to cpu mappings are:
> > core 0 has cpus 0 and 6
> > core 1 has cpus 1 and 7
> >
Hi Pratik,
I tried V3 on a Intel i5-10600K processor with 6 cores and 12 CPUs.
The core to cpu mappings are:
core 0 has cpus 0 and 6
core 1 has cpus 1 and 7
core 2 has cpus 2 and 8
core 3 has cpus 3 and 9
core 4 has cpus 4 and 10
core 5 has cpus 5 and 11
By default, it will test CPUs 0,2,4,6,10 o
Hi Pratik,
On Thu, Apr 1, 2021 at 4:45 AM Pratik Rajesh Sampat
wrote:
>
...
> To run this test specifically:
> $ make -C tools/testing/selftests TARGETS="cpuidle" run_tests
I have not become any smarter than I was with version 1,
and still assumed that the "$" meant regular user.
Please put it
Bas, and Bingsong,
> > On Wed, Mar 10, 2021 at 04:03:31PM -0800, Doug Smythies wrote:
> >> Hi Yu,
> >>
> >> I am just resending your e-mail, adjusting the "To:" list to
> >> include the 3 others that have submitted similar patches.
> >>
>
On Wed, Mar 24, 2021 at 5:38 AM Salvatore Bonaccorso wrote:
> On Mon, Mar 15, 2021 at 10:54:24PM +0100, Christian Kastner wrote:
> > On 01.02.21 10:01, Kurt Garloff wrote:
> > > Issue persists on Ryzen in 5.11-rc6:
> > > kvmadmin@KurtSrv2018(//):~ [0]$ sudo
> > > /casa/src/linux-stable/tools/powe
On Wed, Mar 17, 2021 at 11:44 PM Pratik Sampat wrote:
>
> Hi Doug,
> Thanks for trying these patches out.
>
> On 18/03/21 2:30 am, Doug Smythies wrote:
> > Hi Pratik,
> >
> > It just so happens that I have been trying Artem's version this last
> > we
Hi Pratik,
It just so happens that I have been trying Artem's version this last
week, so I tried yours.
On Mon, Mar 15, 2021 at 4:49 AM Pratik Rajesh Sampat
wrote:
>
...
> To run this test specifically:
> $ make -C tools/testing/selftests TARGETS="cpuidle" run_tests
While I suppose it should ha
w see the field size is only 4 bits for some parts.
... Doug
> Thus, I'm going to revert the patch that added it's use in turbostat
> for the Temperature column.
>
> thanks,
> -Len
>
> On Fri, Mar 12, 2021 at 1:26 AM Doug Smythies wrote:
> >
> > Hi Len,
roduce tcc cooling driver" [1]
And, I spent quite a bit of time doing so.
However, I agree the response seems different between the two systems
under test, Rui's and mine.
[1] https://marc.info/?l=linux-pm&m=161070345329806&w=2
> stay tuned.
O.K.
... Doug
>
> -Len
&
Hi Yu,
I am just resending your e-mail, adjusting the "To:" list to
include the 3 others that have submitted similar patches.
... Doug
On Mon, Mar 8, 2021 at 8:11 AM Chen Yu wrote:
>
> Hi,
> On Mon, Mar 08, 2021 at 07:37:07AM -0800, Doug Smythies wrote:
> > On Mo
On Mon, Mar 8, 2021 at 5:50 AM youling257 wrote:
>
> this cause turbostat not work on amd cpu.
>
> root@localhost:~# /turbostat
> turbostat version 20.09.30 - Len Brown
> CPUID(0): AuthenticAMD 0xd CPUID levels; 0x801f xlevels;
> family:model:stepping 0x17:18:1 (23:24:1)
There are already t
The TCC offset mask is incorrect, resulting in
incorrect target temperature calculations, if
the offset is big enough to exceed the mask size.
Signed-off-by: Doug Smythies
---
tools/power/x86/turbostat/turbostat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/power
On 2020.12.14 12:02 Rafael J. Wysocki wrote:
> Hi,
Hi Rafael,
V2 test results below are new, other results are partially re-stated:
For readers that do not want to read on, I didn't find anything different than
with
the other versions. This was more just due diligence.
Legend:
hwp: Kernel 5.
On 2020.12.08 11:15 Doug wrote:
> On 2020.12.08 09:14 Rafael J. Wysocki wrote:
> > On Tue, Dec 8, 2020 at 5:31 PM Giovanni Gherdovich
> > wrote:
> >> On Mon, 2020-12-07 at 17:25 +0100, Rafael J. Wysocki wrote:
> >> I'd like to test this patch, as I have concerns on how it performs against
> >> t
On 2020.12.08 09:14 Rafael J. Wysocki wrote:
> On Tue, Dec 8, 2020 at 5:31 PM Giovanni Gherdovich
> wrote:
>> On Mon, 2020-12-07 at 17:25 +0100, Rafael J. Wysocki wrote:
>>> Hi,
>>>
>>> This is based on the RFC posted a few days ago:
>>>
>>> https://lore.kernel.org/linux-pm/1817571.2o5Kk4Ohv2@kr
Hi Rafael,
On 2020.11.30 10:37 Rafael J. Wysocki wrote:
> First off, some cpufreq drivers (eg. intel_pstate) can pass hints
> beyond the current target frequency to the hardware and there are no
> provisions for doing that in the cpufreq framework. In particular,
> today the driver has to assume
On 2020.11.10 09:22 Rafael J. Wysocki wrote:
> On Monday, November 9, 2020 5:49:49 PM CET Rafael J. Wysocki wrote:
>>
>> Even after the changes made very recently, the handling of the powersave
>> governor is not exactly as expected when intel_pstate operates in the
>> "passive" mode with HWP enabl
Hi Rafael:
Thank you for this patch set.
I can not get the patch to apply.
I was trying on top on 5.10-rc2, and have been unable to determine
what other patches might need to be applied first.
On 2020.11.05 10:24 Rafael J. Wysocki wrote:
...
>
> Signed-off-by: Rafael J. Wysocki
> ---
> driv
Hi Rafael,
On 2020.08.17 14:06 Doug Smythies wrote:
> On 2020.08.06 05:04 Rafael J. Wysocki wrote:
>
> > Allow intel_pstate to work in the passive mode with HWP enabled and
> > make it set the HWP minimum performance limit (HWP floor) to the
> > P-state value given
Hi Srinivas,
Thanks for your reply.
On 2020.08.25 08:12 Srinivas Pandruvada wrote:
> On Mon, 2020-08-24 at 18:00 -0700, Doug Smythies wrote:
> > I think there is a disconnect between your written
> > description of what is going on and your supporting MSR reads.
> >
> I r
Hi Srinivas,
I think there is a disconnect between your written
description of what is going on and your supporting MSR reads.
On 2020.08.24 16:56 Srinivas Pandruvada wrote:
> On Mon, 2020-08-24 at 19:39 +0200, Rafael J. Wysocki wrote:
> > Hi All,
> >
> > The v2 is here to address feedback from D
On 2020.05.21 10:16 Rafael J. Wysocki wrote:
...
>
> The INTEL_CPUFREQ_TRANSITION_DELAY_HWP value has been guessed and it very well
> may turn out to be either too high or too low for the general use, which is
> one
> reason why getting as much testing coverage as possible is key here.
>
> If y
Hi Rafael,
Just annoying typo type feedback.
On 2020.08.20 09:38 Rafael J. Wysocki wrote:
>
> From: "Rafael J. Wysocki"
>
> Add ->offline and ->online driver callbacksto to do the cleanup
"to to" and suggest this:
Add ->offline and ->online driver callbacks to cleanup
> before taking a CPU
Hi Rafael,
On 2020.08.20 09:35 Rafael J. Wysocki wrote:
>
> The purpose of this series is to address some peculiarities related to
> taking CPUs offline/online and switching between different operation
> modes with HWP enabled that have become visible after allowing the
> driver to work in the pa
On 2020.08.06 05:04 Rafael J. Wysocki wrote:
> Allow intel_pstate to work in the passive mode with HWP enabled and
> make it set the HWP minimum performance limit (HWP floor) to the
> P-state value given by the target frequency supplied by the cpufreq
> governor, so as to prevent the HWP algorithm
On 2020.08.05 09:56 Rafael J. Wysocki wrote:
> v6 -> v7:
>* Cosmetic changes in store_energy_performance_prefernce() to reduce the
> LoC number and make it a bit easier to read. No intentional functional
> impact.
??
V7 is identical to V6.
Diff:
$ diff hwppassive-v6-2-2.patch hwp
On 2020.08.03 10:09 Rafael J. Wysocki wrote:
> On Sunday, August 2, 2020 5:17:39 PM CEST Doug Smythies wrote:
> > On 2020.07.19 04:43 Rafael J. Wysocki wrote:
> > > On Fri, Jul 17, 2020 at 3:37 PM Doug Smythies wrote:
> > > > On 2020.07.16 05:08 Rafael J. Wysocki w
Hi Rafael,
I was just writing you about V5 when this V6 came.
On 2020.08.04 08:11 Rafael J. Wysocki wrote:
...
> This is on top of the material already in the mainline.
Oh, should have read that part better,
but did get there in the end.
...
> v5 -> v6:
>* Fix the problem with the EPP settin
Hi Srinivas,
Thanks for your help. I was missing several needed patches.
On 2020.08.02 11:39 Srinivas Pandruvada wrote:
> On Sun, 2020-08-02 at 07:00 -0700, Doug Smythies wrote:
> > On 2020.08.01 09:40 Srinivas Pandruvada wrote:
> > > > On Monday, July 27, 2020 5:13:40 PM C
Hi Rafael,
On 2020.07.19 04:43 Rafael J. Wysocki wrote:
> On Fri, Jul 17, 2020 at 3:37 PM Doug Smythies wrote:
> > On 2020.07.16 05:08 Rafael J. Wysocki wrote:
> > > On Wed, Jul 15, 2020 at 10:39 PM Doug Smythies
> > > wrote:
> > >> On 2
On 2020.08.01 16:41 Srinivas Pandruvada wrote:
> On Tue, 2020-07-28 at 17:13 +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Allow intel_pstate to work in the passive mode with HWP enabled and
> > make it set the HWP minimum performance limit (HWP floor) to the
> > P-state valu
On 2020.08.01 09:40 Srinivas Pandruvada wrote:
>> On Monday, July 27, 2020 5:13:40 PM CEST Rafael J. Wysocki wrote:
>>> On Thursday, July 16, 2020 7:37:04 PM CEST Rafael J. Wysocki wrote:
This really is a v2 of this patch:
https://patchwork.kernel.org/patch/11663271/
with a
Hi Rafael,
Thank you for your reply.
On 2020.07.16 05:08 Rafael J. Wysocki wrote:
> On Wed, Jul 15, 2020 at 10:39 PM Doug Smythies wrote:
>> On 2020.07.14 11:16 Rafael J. Wysocki wrote:
>> >
>> > From: Rafael J. Wysocki
>> ...
>> > Since the passive
On 2020.07.14 11:16 Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
...
> Since the passive mode hasn't worked with HWP at all, and it is not going to
> the default for HWP systems anyway, I don't see any drawbacks related to
> making
> this change, so I would consider this as 5.9 material
mmand line doesn't work, so
> fix that.
>
> Fixes: 33aa46f252c7 ("cpufreq: intel_pstate: Use passive mode by default
> without HWP")
> Reported-by: Doug Smythies
> Signed-off-by: Rafael J. Wysocki
Acked-by: Doug Smythies
> ---
> drivers/cpufreq/intel_
Hi Rafael,
As you may or may not recall, I am attempting to untangle
and separate multiple compounding issues around the
intel_pstate driver and HWP (or not).
Until everything is figured out, I am using the following rules:
. never use x86_energy_perf_policy.
. For HWP disabled: never change fro
Hi Srinivas,
Thanks for all your work on this.
I have fallen behind, and not sure when I can catch up.
However...
On 2020.06.26 11:34 Srinivas Pandruvada wrote:
> Similarly on battery the default "balance_performance" mode can be
> aggressive in power consumption. But picking up the next choice
Hi Srinivas,
I saw your V3.
I do not understand your reluctance to use
arch/x86/include/asm/msr-index.h
as the place to define anything MSR related.
Please explain.
One more comment about 1/3 of the way down below.
... Doug
On 2020.06.23 08:53 Doug Smythies wrote:
> On 2020.06.22 22
Hi Srinivas,
I have immediate need for this. I have been using a tool
I wrote myself for this which I can now retire.
(it wasn't very good anyway).
Yours remembers for each governor, and is way better.
Thanks.
On 2020.06.23 11:27 Srinivas Pandruvada wrote:
> Currently using attribute "energy_per
Hi Quentin,
Thanks for your quick reply.
On 2020.06.23 11:05 Quentin Perret wrote:
> Hi Doug,
>
> On Tuesday 23 Jun 2020 at 10:54:33 (-0700), Doug Smythies wrote:
> > Hi Quentin,
> >
> > Because I am lazy and sometimes do not want to recompile
> > the distro
On 2020.06.23 07:22 Quentin Perret wrote:
>
> This series enables users of prebuilt kernels (e.g. distro kernels) to
> specify their CPUfreq governor of choice using the kernel command line,
> instead of having to wait for the system to fully boot to userspace to
> switch using the sysfs interface
On 2020.06.22 22:13 Srinivas Pandruvada wrote:
> By default intel_pstate driver disables energy efficiency by setting
> MSR_IA32_POWER_CTL bit 19 for Kaby Lake desktop CPU model in HWP mode.
> This CPU model is also shared by Coffee Lake desktop CPUs. This allows
> these systems to reach maximum p
On 2020.05.21 10:16 Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
>
> Allow intel_pstate to work in the passive mode with HWP enabled and
> make it translate the target frequency supplied by the cpufreq
> governor in use into an EPP value to be written to the HWP request
> MSR (high frequ
On 2020.06.11 10:49 Srinivas Pandruvada wrote:
> Add additional bit for OOB (Out of band) enabling of P-states. In this
> case intel_pstate shouldn't load. Currently, only "BIT(8) == 1" of the
> MSR MSR_MISC_PWR_MGMT is considered as OOB. Also add "BIT(18) == 1" as
> OOB condition.
Shouldn't thos
On 2020.06.05 Rafael J. Wysocki wrote:
> On 6/4/2020 11:29 PM, Alexander Monakov wrote:
> > Hello,
>
> Hi,
>
> Let's make more people see your report.
>
> +Peter, Giovanni, Quentin, Juri, Valentin, Vincent, Doug, and linux-pm.
>
>> this is a question/bugreport about behavior of schedutil on ser
pstate/powersave hwp idle state 2 disabled:
>
> Overruns: 3
> Ave. work percent: 66.647895
> Processor package power: ~16.8 watts.
> Average CPU frequency: 4.6 gigahertz
>
> intel_pstate/powersave hwp idle state 3 disabled:
>
> Overruns: 22
> Ave. work percent: 66.64
Hi Rafael,
As you well know, I often test first and
ask questions and review code later.
I think I should have questioned this first.
To the best of my ability/availability, I am
committed to follow up on the hwp issue raised on
the other branch of this thread. However, moving
forward the typica
On 2020.05.31 12:29 Srinivas Pandruvada wrote:
> On Sun, 2020-05-31 at 11:59 -0700, Srinivas Pandruvada wrote:
>> On Sun, 2020-05-31 at 11:06 -0700, Doug Smythies wrote:
>> > Hi Srinivas,
>> >
>> > Thanks you for your quick reply.
>> >
>> > O
Hi Srinivas,
Thanks you for your quick reply.
On 2020.05.31 09:54 Srinivas Pandruvada wrote
> On Sun, 2020-05-31 at 09:39 -0700, Doug Smythies wrote:
>> Event begins at 17.456 seconds elapsed time.
>> Previous event was about 107 milliseconds ago.
>>
>> Old min
Correction:
On 2020.05.31 09:39 Doug smythies wrote:
> The overruns and use of idle state 0 are exactly correlated.
Should have been "idle state 2":
The overruns and use of idle state 2 are exactly correlated.
e, the link is coded:
[1] double u double u double u dot smythies dot com
/~doug/linux/s18/hwp/index.html
... Doug
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: May 26, 2020 11:21 AM
> To: Linux PM; Doug Smythies
> Cc: LKML; Len Brown; Sr
On 2020.05.26 01:19 Rafael J. Wysocki wrote:
> to On Mon, May 25, 2020 at 10:57 PM Francisco Jerez
> > "Rafael J. Wysocki" writes:
> > > On Mon, May 25, 2020 at 3:39 AM Francisco Jerez
> >
> > Why not HWP_MIN_PERF? That would leave the HWP quite some room for
> > maneuvering (the whole HWP_MIN_P
Hi all,
The INTEL_CPUFREQ_TRANSITION_DELAY_HWP = 2
test results from this e-mail were incorrect.
The test and graphs are being re-done.
On 2020.05.25 08:30 Doug smythies wrote:
>
> Legend - intel_pstate - powersave graph [2].
>
> What? Why is there such a graph, unrelated t
On 2020.05.21 04:09 Pratik Sampat wrote:
> On 17/05/20 11:41 pm, Doug Smythies wrote:
> > On 2020.05.11 Pratik Rajesh Sampat wrote:
> >> First RFC posting:https://lkml.org/lkml/2020/2/22/27
> > Summary:
> >
> > On that thread I wrote:
> >
> >
On 2020.05.21 10:16 Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
>
> Allow intel_pstate to work in the passive mode with HWP enabled and
> make it translate the target frequency supplied by the cpufreq
> governor in use into an EPP value to be written to the HWP request
> MSR (high freq
On 2020.05.11 Pratik Rajesh Sampat wrote:
>
> First RFC posting: https://lkml.org/lkml/2020/2/22/27
Summary:
On that thread I wrote:
> 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.
I tried your tests, or
On 2019.10.10 Rafael J. Wysocki wrote:
> There are a few issues related to the handling of disabled idle states in the
> TEO (Timer-Events-Oriented) cpuidle governor which are addressed by this
> series.
>
> The application of the entire series is exactly equivalent to the testing
> patch
> at ht
On 2019.10.09 06:37 Rafael J. Wysocki wrote:
> On Wednesday, October 9, 2019 1:19:51 AM CEST Rafael J. Wysocki wrote:
>> On Tuesday, October 8, 2019 12:49:01 PM CEST Rafael J. Wysocki wrote:
>>> On Tue, Oct 8, 2019 at 11:51 AM Rafael J. Wysocki wrote:
>>>> On Tu
On 2019.10.06 08:34 Rafael J. Wysocki wrote:
> On Sun, Oct 6, 2019 at 4:46 PM Doug Smythies wrote:
>> On 2019.10.01 02:32 Rafael J. Wysocki wrote:
>>> On Sun, Sep 29, 2019 at 6:05 PM Doug Smythies wrote:
>>>> On 2019.09.26 09:32 Doug Smythies wrote:
>>&
On 2019.10.01 02:32 Rafael J. Wysocki wrote:
> On Sun, Sep 29, 2019 at 6:05 PM Doug Smythies wrote:
>> On 2019.09.26 09:32 Doug Smythies wrote:
>>
>>> If the deepest idle state is disabled, the system
>>> can become somewhat unstable, with anywhere between no prob
On 2019.09.26 09:32 Doug Smythies wrote:
> If the deepest idle state is disabled, the system
> can become somewhat unstable, with anywhere between no problem
> at all, to the occasional temporary jump using a lot more
> power for a few seconds, to a permanent jump using a lot
All,
Recall the extensive tests and work done between 2018.10.11 and 2019.01.16
on Rafael's teo governor, versions 1 through 11, noting that versions
9, 10, and 11 did not contain functional changes.
Hi Rafael,
If the deepest idle state is disabled, the system
can become somewhat unstable, with
On 2019.09.24 01:06 Mel Gorman wrote:
> On Thu, Sep 19, 2019 at 07:42:29AM -0700, Doug Smythies wrote:
>> On 2019.09.17 07:25 Giovanni Gherdovich wrote:
>>>On Wed, 2019-09-11 at 08:28 -0700, Doug Smythies wrote:
>>> [...]
>
> Hence, I think this patchset shoul
Hi Giovanni,
Thank you for your detailed reply.
On 2019.09.17 07:25 Giovanni Gherdovich wrote:
>On Wed, 2019-09-11 at 08:28 -0700, Doug Smythies wrote:
> [...]
>> The problem with the test is its run to run variability, which was from
>> all the disk I/O, as far as I could
On 2019.09.11 08:28 Doug Smythies wrote:
> Hi Giovanni,
>
> Thank you for the great detail and test results you provided.
>
> On 2019.09.08.07:42 Giovanni Gherdovich wrote:
>
> ... [snip]...
>
>> The test we call "gitsource" (running the git unit test
Hi Giovanni,
Thank you for the great detail and test results you provided.
On 2019.09.08.07:42 Giovanni Gherdovich wrote:
... [snip]...
> The test we call "gitsource" (running the git unit test suite, a long-running
> single-threaded shell script) appears rather spectacular in this table (gains
On 2019.08.08 19:16 Viresh Kumar wrote:
> On 08-08-19, 09:25, Doug Smythies wrote:
>> On 2019.08.07 00:06 Viresh Kumar wrote:
>> Tested by: Doug Smythies
>> Thermald seems to now be working O.K. for all the governors.
>
> Thanks for testing Doug.
>
>> I do n
On 2019.08.08 19:23 Viresh Kumar wrote:
> ---
> V4->V5:
> - dev_pm_qos_update_request() can return 1 in case of success, handle
> that.
O.K. thanks,
That fixes the "Fail" messages I was getting with V4.
... Doug
e mode.
>
> Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
> Reported-by: Doug Smythies
> Signed-off-by: Viresh Kumar
Tested by: Doug Smythies
Thermald seems to now be working O.K. for all the governors.
I do note that if one sets
/sys/device
On 2019.08.02 02:28 Rafael J. Wysocki wrote:
> On Friday, August 2, 2019 11:17:55 AM CEST Rafael J. Wysocki wrote:
>> On Fri, Aug 2, 2019 at 7:44 AM Viresh Kumar wrote:
>>>
>>> Intel pstate driver exposes min_perf_pct and max_perf_pct sysfs files,
>>> which can be used to force a limit on the min/
where the flag gets cleared without forcing us
>> to change the frequency at least once. And so this patch introduces
>> another flag to avoid that race condition.
>>
>> Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
>> Cc: v4
On 2019.07.31 23:17 Viresh Kumar wrote:
> On 31-07-19, 17:20, Doug Smythies wrote:
>> Summary:
>>
>> The old way, using UINT_MAX had two purposes: first,
>> as a "need to do a frequency update" flag; but also second, to
>> force any subsequent old/n
ki wrote:
> On Mon, Jul 29, 2019 at 10:32 AM Viresh Kumar wrote:
>> On 29-07-19, 00:55, Doug Smythies wrote:
>>> On 2019.07.25 23:58 Viresh Kumar wrote:
...[snip]...
>>>> Now, the frequency never gets down and so gets set to the maximum
>>>> possible aft
always get the frequency
> within the new limits as soon as possible.
>
> Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
> Cc: v4.18+ # v4.18+
> Reported-by: Doug Smythies
> Signed-off-by: Viresh Kumar
> ---
> @Doug: Can yo
On 2019.07.25 23:58 Viresh Kumar wrote:
> On 25-07-19, 08:20, Doug Smythies wrote:
>> I tried the patch ("patch2"). It did not fix the issue.
>>
>> To summarize, all kernel 5.2 based, all intel_cpufreq driver and schedutil
>> governor:
>>
>> Test
Hi,
I am having trouble keeping up.
Here is what I have so far:
On 2019.07.24 04:43 Viresh Kumar wrote:
> On 23-07-19, 12:27, Rafael J. Wysocki wrote:
>> On Tue, Jul 23, 2019 at 11:15 AM Viresh Kumar
>> wrote:
>>> Though there is one difference between intel_cpufreq and acpi_cpufreq,
>>> intel
ould always get the frequency
> within limits as soon as possible.
>
> Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
> Cc: v4.18+ # v4.18+
> Reported-by: Doug Smythies
> Signed-off-by: Viresh Kumar
> ---
> @Doug: Please try thi
On 2019.07.18 03:28 Viresh Kumar wrote:
> On 17-07-19, 23:26, Doug Smythies wrote:
>> This reverts commit ecd2884291261e3fddbc7651ee11a20d596bb514.
>>
>> The commit caused a regression whereby reducing the maximum
>> CPU clock frequency is ineffective while busy, a
This reverts commit ecd2884291261e3fddbc7651ee11a20d596bb514.
The commit caused a regression whereby reducing the maximum
CPU clock frequency is ineffective while busy, and the CPU
clock remains unchanged. Once the system has experienced
some idle time, the new limit is implemented.
A consequence
On 2019.07.03 12:12 Doug Smythies wrote:
> On 2019.07.03 08:16 Daniel Lezcano wrote:
>> On 03/07/2019 16:23, Doug Smythies wrote:
>>> On 2019.06.20 04:58 Daniel Lezcano wrote:
> ...
>>> Anyway, I did a bunch of tests and such, but have deleted
>>> most fr
On 2019.07.03 08:16 Daniel Lezcano wrote:
> On 03/07/2019 16:23, Doug Smythies wrote:
>> On 2019.06.20 04:58 Daniel Lezcano wrote:
...
>> Anyway, I did a bunch of tests and such, but have deleted
>> most from this e-mail, because it's just noise. I'll
>> in
Hi Daniel,
I tried your "mobile" governor, albeit not on a mobile device.
On 2019.06.20 04:58 Daniel Lezcano wrote:
...
> The mobile governor is a new governor targeting embedded systems
> running on battery where the energy saving has a higher priority than
> servers or desktops. This governor
On 2019.07.01 08:34 Alan Jenkins wrote:
> Hi
Hi,
> I tried running a simple test:
>
> dd if=testfile iflag=direct bs=1M of=/dev/null
>
> With my default settings, `vmstat 10` shows something like 85% idle time
> to 15% iowait time. I have 4 CPUs, so this is much less than one CPU
> worth o
On 2019.06.13 01:53 Rafael J. Wysocki wrote:
> I personally doubt that any thermal throttling is involved here.
In earlier e-mails on this thread, Pavel showed his core and package
temperatures as 97 and 98 degrees. If thermal throttling is not
involved, it should be. The description of the obser
On 2019.06.12 14:25 Rafael J. Wysocki wrote:
> On Wed, Jun 12, 2019 at 4:45 AM Doug Smythies wrote:
>>
>> So, currently there seems to be 3 issues in this thread
>> (and I am guessing a little, without definitive data):
>>
>> 1.) On your system Kernel 5.4-rc2 (o
Hi,
So, currently there seems to be 3 issues in this thread
(and I am guessing a little, without definitive data):
1.) On your system Kernel 5.4-rc2 (or 4) defaults to the intel_pstate CPU
frequency
scaling driver and the powersave governor, but kernel 4.6 defaults to the
acpi-cpufreq CPU freque
On 2019.02.07 03:51 Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The current iowait boosting mechanism in intel_pstate_update_util()
> is quite aggressive, as it goes to the maximum P-state right away,
> and may cause excessive amounts of energy to be used, which is not
> desirable and
On 2019.02.05 04:04 Rafael J. Wysocki wrote:
> On Friday, February 1, 2019 5:54:37 PM CET Doug Smythies wrote:
>> On 2019.01.30 16:05 Rafael J. Wysocki wrote:
>>
>>> From: Rafael J. Wysocki
>>>
>>> The current iowait boosting mechanism in intel_pstate_up
On 2019.01.30 16:05 Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The current iowait boosting mechanism in intel_pstate_update_util()
> is quite aggressive, as it goes to the maximum P-state right away,
> and may cause excessive amounts of energy to be used, which is not
> desirable and
d-off-by: Doug Smythies
---
drivers/cpuidle/poll_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpuidle/poll_state.c b/drivers/cpuidle/poll_state.c
index b17d153..23a1b27 100644
--- a/drivers/cpuidle/poll_state.c
+++ b/drivers/cpuidle/poll_state.c
@@ -21,7
Hi Rafael,
Just typos, not already pointed out by Quentin:
On 2018.12.18 03:09 Rafael J. Wysocki wrote:
> The venerable menu governor does some thigns that are quite
s/thigns/things
> time frame in which no timer wakeups are possible (becuase it knows
s/because/because
> +obtain the the *sle
35459105deb26430653a7299a86bc66fb4dd5773
tools/power/x86/intel_pstate_tracer: Add optional setting of trace buffer
memory allocation
moved the code but kept the bug.
This patch fixes the issue.
Signed-off-by: Doug Smythies
---
tools/power/x86/intel_pstate_tracer/intel_pstate_tracer.py | 4 ++--
1
On 2018.12.11 03:50 Rafael J. Wysocki wrote:
...[snip]...
> With this version of the TEO governor I'm observing slight, but consistent
> performance improvements in some different benchmarks on a few different
> systems with respect to menu
Same here.
> and the corresponding power draw differen
On 2018.12.13 04:42 Paul Menzel wrote:
> On 12/13/18 11:39, Rafael J. Wysocki wrote:
>> On Thu, Dec 13, 2018 at 10:54 AM Paul Menzel wrote:
>>> On 12/13/18 00:06, Doug Smythies wrote:
>>>> On 2018.12.12 13:40 Paul Menzel wrote:
>>>>
>>>>>
On 2018.12.12 13:40 Paul Menzel wrote:
> Using *powersave* as P-state selection algorithm, on an idle system
Define "idle system".
If your computer is running a GUI, or is even a server without a GUI
but with many services running, then "idle" really isn't.
Below is from my test server, with many
On 2018.12.10 02:52 Peter Zijlstra wrote:
>On Mon, Dec 10, 2018 at 10:36:40PM +0100, Rafael J. Wysocki wrote:
>> On Mon, Dec 10, 2018 at 1:21 PM Peter Zijlstra wrote:
>>> Would not a tracepoint be better?; then there is no overhead in the
>>> normal case where nobody gives a crap about these here
On 2018.12.06 01:09 Rafael J. Wysocki wrote:
> On Thu, Dec 6, 2018 at 12:08 AM Doug Smythies wrote:
>> On 2018.12.03 04:32 Rafael J. Wysocki wrote:
>>
>>> Add two new metrics for CPU idle states, "high" and "low", to count
>>> the number of
s I was making.
Eventually (probably several days) I'll report back my test
results.
> Some specific remarks you raise:
>
> On Mon, 2018-12-03 at 08:23 -0800, Doug Smythies wrote:
>> ...
>> My issue is that I do not understand the output or how it
>> might corre
On 2018.12.03 03:48 Rafael J. Wysocki wrote:
>>> There is an additional issue where if idle state 0 is disabled (with the
>>> above suggested code patch),
>>> idle state usage seems to fall to deeper states than idle state 1.
>>> This is not the expected behaviour.
>>
>> No, it isn't.
>>
>>> Ke
1 - 100 of 270 matches
Mail list logo
