Looks good to me, series is:
Reviewed-by: Francisco Jerez
Matt Roper writes:
> This structure has a great comment describing the fields, but it's not
> currently in kerneldoc form and does not show up in the generated
> documentation. Let's fix that and also clarify the
Daniel Vetter writes:
> On Wed, Mar 30, 2022 at 02:53:11PM -0700, Matt Atwood wrote:
>> Newer platforms have DSS that aren't necessarily available for both
>> geometry and compute, two queries will need to exist. This introduces
>> the first, when passing a valid engine class and engine instance
Matt Atwood writes:
> Newer platforms have DSS that aren't necessarily available for both
> geometry and compute, two queries will need to exist. This introduces
> the first, when passing a valid engine class and engine instance in the
> flags returns a topology describing geometry.
>
> v2: fix w
Daniel Vetter writes:
> On Mon, May 10, 2021 at 3:55 PM Martin Peres wrote:
>>
>> On 10/05/2021 02:11, Jason Ekstrand wrote:
>> > On May 9, 2021 12:12:36 Martin Peres wrote:
>> >
>> >> Hi,
>> >>
>> >> On 06/05/2021 22:13, Matthew Brost wrote:
>> >>> Basic GuC submission support. This is the fir
Joonas Lahtinen writes:
> + Jason and Ken
>
> Quoting Francisco Jerez (2020-06-05 00:34:57)
>> Ayaz A Siddiqui writes:
>>
>> > In order to avoid functional breakage of mis-programmed applications that
>> > have grown to depend on unused MOCS entries, we a
Ayaz A Siddiqui writes:
> In order to avoid functional breakage of mis-programmed applications that
> have grown to depend on unused MOCS entries, we are programming
> those entries to be equal to fully cached ("L3 + LLC") entry as per the
> recommendation from architecture team.
>
> These reserv
"Rafael J. Wysocki" writes:
> On Monday, May 11, 2020 11:01:41 PM CEST Francisco Jerez wrote:
>>
>> --==-=-=
>> Content-Type: multipart/mixed; boundary="=-=-="
>>
>> --=-=-=
>> Content-Type: text/plain; charset=utf-8
>> Content-D
Valentin Schneider writes:
> (+Lukasz)
>
> On 11/05/20 22:01, Francisco Jerez wrote:
>>> What I'm missing is an explanation for why this isn't using the
>>> infrastructure that was build for these kinds of things? The thermal
>>> framework, was AFAI
Peter Zijlstra writes:
> On Mon, Apr 27, 2020 at 08:22:47PM -0700, Francisco Jerez wrote:
>> This addresses the technical concerns people brought up about my
>> previous v2 revision of this series. Other than a few bug fixes, the
>> only major change relative to v2 is that
wax[0] writes:
> Hi Francisco,
n>
> I am very interested in installing the patch to improve intel_pstate, I am
> runing ubuntu 20.04 on a Surface Pro 7 with Ice Lake processor and I get some
> issues with the computer freezing for few seconds randomly, it is specially
> annoying because the cu
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 9 ++---
include/trace/events/power.h | 13 +
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 2458a821195f..dd86505d7855
This addresses the technical concerns people brought up about my
previous v2 revision of this series. Other than a few bug fixes, the
only major change relative to v2 is that the controller is now exposed
as a new CPUFREQ generic governor as requested by Rafael (named
"adaptive" in this RFC though
v3: Rename CPU_RESPONSE_FREQUENCY to CPU_SCALING_RESPONSE (Rafael).
Signed-off-by: Francisco Jerez
---
include/linux/pm_qos.h | 9 +++
include/trace/events/power.h | 33 +
kernel/power/qos.c | 131 ++-
3 files changed, 155 insertions(+), 18
And let it figure out whether an update_util hook is needed, and what
the appropriate function pointer is based on the CPUFREQ policy of the
current CPU.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions
CPU or another IO device.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/cpufreq.c | 10 --
drivers/cpufreq/longrun.c | 1 +
include/linux/cpufreq.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index
ael).
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 0a315f681c43..2458a821195f 100644
--- a/drivers/cpufreq/intel_ps
-off-by: Francisco Jerez
Signed-off-by: Fengguang Wu
Signed-off-by: Julia Lawall
---
drivers/cpufreq/intel_pstate.c | 86 ++
1 file changed, 86 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index dd86505d7855
accidental overwrite of boot EPP setting in
intel_pstate_reset_vlp() (Srinivas). Rename
CPU_RESPONSE_FREQUENCY to CPU_SCALING_RESPONSE (Rafael). Define
generic CPUFREQ policy to control VLP governor (Rafael).
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pst
Trivial.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 66ab6523c3eb..49401cfe9858 100644
--- a/drivers/cpufreq
control VLP governor (Rafael). Adjust
realtime_gain_pml to avoid fluctuation of minimum P-state on HWP
parts (Srinivas).
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 398 +
1 file changed, 398 insertions(+)
diff --git a/drivers
v3: Rename CPU_RESPONSE_FREQUENCY to CPU_SCALING_RESPONSE (Rafael).
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/i915/i915_debugfs.c | 69 +
1 file changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915
ias due to interrupt
latency (Francisco). Rename CPU_RESPONSE_FREQUENCY to
CPU_SCALING_RESPONSE (Rafael). Adjust heuristic parameters to
avoid regressions from other v3 governor changes (Francisco).
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c|
Chris Wilson writes:
> If we use a non-forcewaked write to PMINTRMSK, it does not take effect
> until much later, if at all, causing a loss of RPS interrupts and no GPU
> reclocking, leaving the GPU running at the wrong frequency for long
> periods of time.
>
> Reported-b
Francisco Jerez writes:
> Chris Wilson writes:
>
>> Quoting Francisco Jerez (2020-04-14 22:00:25)
>>> Chris Wilson writes:
>>>
>>> > Quoting Francisco Jerez (2020-04-14 20:39:48)
>>> >> Chris Wilson writes:
>>> >>
>&
Chris Wilson writes:
> Quoting Francisco Jerez (2020-04-14 22:00:25)
>> Chris Wilson writes:
>>
>> > Quoting Francisco Jerez (2020-04-14 20:39:48)
>> >> Chris Wilson writes:
>> >>
>> >> > Quoting Chris Wilson (2020-04-14 17:
Chris Wilson writes:
> Quoting Francisco Jerez (2020-04-14 20:39:48)
>> Chris Wilson writes:
>>
>> > Quoting Chris Wilson (2020-04-14 17:14:23)
>> >> Try to make RPS dramatically more responsive by shrinking the evaluation
>> >> intervales by
Chris Wilson writes:
> Quoting Francisco Jerez (2020-04-14 20:39:48)
>> Chris Wilson writes:
>>
>> > Quoting Chris Wilson (2020-04-14 17:14:23)
>> >> Try to make RPS dramatically more responsive by shrinking the evaluation
>> >> intervales by
Chris Wilson writes:
> Quoting Chris Wilson (2020-04-14 17:14:23)
>> Try to make RPS dramatically more responsive by shrinking the evaluation
>> intervales by a factor of 100! The issue is as we now park the GPU
>> rapidly upon idling, a short or bursty workload such as the composited
>> desktop
Chris Wilson writes:
> Quoting Francisco Jerez (2020-03-23 22:30:13)
>> Chris Wilson writes:
>>
>> > Quoting Francisco Jerez (2020-03-20 22:14:51)
>> >> Francisco Jerez writes:
>> >>
>> >> > Chris Wilson writes:
>>
Francisco Jerez writes:
> "Pandruvada, Srinivas" writes:
>
>> Hi Francisco,
>>
>> On Tue, 2020-03-10 at 14:41 -0700, Francisco Jerez wrote:
>>> This is my second take on improving the energy efficiency of the
>>> intel_pstate driver under I
"Pandruvada, Srinivas" writes:
> Hi Francisco,
>
> On Tue, 2020-03-10 at 14:41 -0700, Francisco Jerez wrote:
>> This is my second take on improving the energy efficiency of the
>> intel_pstate driver under IO-bound conditions. The problem and
>> approach t
Chris Wilson writes:
> Quoting Francisco Jerez (2020-03-20 22:14:51)
>> Francisco Jerez writes:
>>
>> > Chris Wilson writes:
>> >
>> >> We dropped calling process_csb prior to handling direct submission in
>> >> order to avoi
Francisco Jerez writes:
> Chris Wilson writes:
>
>> We dropped calling process_csb prior to handling direct submission in
>> order to avoid the nesting of spinlocks and lift process_csb() and the
>> majority of the tasklet out of irq-off. However, we do want to avoid
>
and pull the interrupt-bh
> local to direct submission if we can acquire the tasklet's lock.
>
> v2: Tweak the balance to avoid over submitting lite-restores
>
> Signed-off-by: Chris Wilson
> Cc: Francisco Jerez
> Cc: Tvrtko Ursulin
> ---
>
Francisco Jerez writes:
> Francisco Jerez writes:
>
>> Chris Wilson writes:
>>
>>> Quoting Francisco Jerez (2020-03-10 21:41:55)
>>>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>>>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
>>>>
"Pandruvada, Srinivas" writes:
> On Wed, 2020-03-18 at 12:51 -0700, Francisco Jerez wrote:
>> "Pandruvada, Srinivas" writes:
>>
>> > On Tue, 2020-03-10 at 14:42 -0700, Francisco Jerez wrote:
>> > > This implements a simple variably low-
"Pandruvada, Srinivas" writes:
> On Tue, 2020-03-10 at 14:42 -0700, Francisco Jerez wrote:
>> This implements a simple variably low-pass-filtering governor in
>> control of the HWP MIN/MAX PERF range based on the previously
>> introduced get_vlp_target_range
Francisco Jerez writes:
> Chris Wilson writes:
>
>> Quoting Francisco Jerez (2020-03-10 21:41:55)
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
>>> index b9b3f78f1324..a5d7a80b826d 100644
>>> ---
Francisco Jerez writes:
> Tvrtko Ursulin writes:
>[...]
>> Some time ago we entertained the idea of GPU "load average", where that
>> was defined as a count of runnable requests (so batch buffers). How
>> that, more generic metric, would behave here if
Lionel Landwerlin writes:
> On 15/03/2020 02:12, Francisco Jerez wrote:
>> srinivasa...@intel.com writes:
>>
>>> From: Srinivasan S
>>>
>>>drm/i915: Context aware user agnostic EU/Slice/Sub-slice control
>>> within kernel
>>>
srinivasa...@intel.com writes:
> From: Srinivasan S
>
> drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within
> kernel
>
> This patch sets improves GPU power consumption on Linux kernel based OS such
> as
> Chromium OS, Ubuntu, etc. Following are the power savings.
>
> P
Tvrtko Ursulin writes:
> On 11/03/2020 19:54, Francisco Jerez wrote:
>> Tvrtko Ursulin writes:
>>
>>> On 10/03/2020 22:26, Chris Wilson wrote:
>>>> Quoting Francisco Jerez (2020-03-10 21:41:55)
>>>>> diff --git a/drivers/gpu/drm/i915/gt/intel
Tvrtko Ursulin writes:
> On 10/03/2020 22:26, Chris Wilson wrote:
>> Quoting Francisco Jerez (2020-03-10 21:41:55)
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
>>> index b9b3f78f1324..a5d7a80b826d 1006
ned-off-by: Francisco Jerez
---
include/linux/pm_qos.h | 9 +++
include/trace/events/power.h | 33 +
kernel/power/qos.c | 138 ++-
3 files changed, 162 insertions(+), 18 deletions(-)
diff --git a/include/linux/pm_qos.h b/include/linux/pm_q
Peter Zijlstra writes:
> On Tue, Mar 10, 2020 at 02:41:54PM -0700, Francisco Jerez wrote:
>> +static void cpu_response_frequency_qos_apply(struct pm_qos_request *req,
>> + enum pm_qos_req_action action,
>> +
"Pandruvada, Srinivas" writes:
> On Tue, 2020-03-10 at 14:41 -0700, Francisco Jerez wrote:
>>
>
> [...]
>
>> Thanks in advance for any review feed-back and test reports.
>>
>> [PATCH 01/10] PM: QoS: Add CPU_RESPONSE_FREQUENCY global PM QoS
>
Chris Wilson writes:
> Quoting Francisco Jerez (2020-03-10 21:41:55)
>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
>> index b9b3f78f1324..a5d7a80b826d 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
>> +++ b/dr
This reverts commit c4f3f70cacba2fa19545389a12d09b606d2ad1cf. A
future commit will introduce a new update_util implementation, so the
pstate_funcs table entry is going to be useful.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 17 +
1 file changed, 13
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 9 ++---
include/trace/events/power.h | 13 +
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 050cc8f03c26..c4558a131660
: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 157 +
1 file changed, 157 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 12ee350db2a9..cecadfec8bc1 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers
the kernel about
I/O utilization and scheduling behavior.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 230 +
1 file changed, 230 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 8cb5bf419b40
pplication (A
more fine-grained result could be achieved with a scheduling-based
interface). The default value needs to be equal to zero (best effort)
for it to behave as identity of the MAX operation.
Signed-off-by: Francisco Jerez
---
include/linux/pm_qos.h | 9 +++
include/trace/even
s out there
improve significantly in the TDP-constrained platforms where this is
currently enabled, see the cover letter for some numbers). If the
workload isn't (anymore) TDP-limited performance should stay roughly
constant, but energy usage will be divided by a similar factor.
Signed-off-by:
behavior (e.g. to test on other
platforms) the VLP controller can be forcefully enabled or disabled by
passing "intel_pstate=vlp" or "intel_pstate=no_vlp" respectively in
the kernel command line.
v2: Handle HWP VLP controller.
Signed-off-by: Francisco Jerez
---
..
calibration of the heuristic to be obvious in bug
reports.
v2: Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
for debugfs files (Julia). Add realtime statistic threshold and
averaging frequency parameters.
Signed-off-by: Francisco Jerez
Signed-off-by: Fengguang Wu
Signed-off-by
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/i915/i915_debugfs.c | 69 +
1 file changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8f2525e4ce0f..e5c27b9302d9 100644
--- a/drivers/gpu/drm/i915
This implements a simple variably low-pass-filtering governor in
control of the HWP MIN/MAX PERF range based on the previously
introduced get_vlp_target_range(). See "cpufreq: intel_pstate:
Implement VLP controller target P-state range estimation." for the
rationale.
Signed-off-by:
This is my second take on improving the energy efficiency of the
intel_pstate driver under IO-bound conditions. The problem and
approach to solve it are roughly the same as in my previous series [1]
at a high level:
In IO-bound scenarios (by definition) the throughput of the system
doesn't improv
en12+")
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Thanks. This makes things easier for userspace until the
modifiers-based alternative to this is in better shape.
Reviewed-by: Francisco Jerez
> ---
> drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 7 ---
> 1 file ch
5/tgl: Define MOCS entries for Tigerlake")
> Cc: Tomasz Lis
> Cc: Lucas De Marchi
> Cc: Francisco Jerez
> Cc: Jon Bloomfield
> Signed-off-by: Matt Roper
Reviewed-by: Francisco Jerez
> ---
> drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +-
> 1 file changed, 1 in
userspace
> software that mistakenly uses these entries (which are undefined on ICL)
> sees the same behavior it sees with all the other undefined entries.
>
> Cc: Francisco Jerez
> Cc: Jon Bloomfield
> Cc: Lucas De Marchi
> Signed-off-by: Matt Roper
I think f4071997f1de0
Chris Wilson writes:
> Quoting Francisco Jerez (2019-07-24 21:37:24)
>> Chris Wilson writes:
>>
>> > Since userspace has the ability to bypass the CPU cache from within its
>> > unprivileged command stream, we have to flush the CPU cache to memory
>&g
Jani Nikula writes:
> Allow better abstraction of the drm_debug global variable in the
> future. No functional changes.
>
> Cc: Francisco Jerez
> Signed-off-by: Jani Nikula
Reviewed-by: Francisco Jerez
> ---
> drivers/gpu/drm/i2c/sil164_drv.c | 2 +-
> 1 file ch
Chris Wilson writes:
> Since userspace has the ability to bypass the CPU cache from within its
> unprivileged command stream, we have to flush the CPU cache to memory
> in order to overwrite the previous contents on creation.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: stablevge
Chris Wilson writes:
> Quoting Francisco Jerez (2019-07-23 23:19:13)
>> Chris Wilson writes:
>>
>> > Quoting Tvrtko Ursulin (2019-07-22 12:41:36)
>> >>
>> >> On 20/07/2019 15:31, Chris Wilson wrote:
>> >> > Enabling atomic op
Chris Wilson writes:
> Quoting Tvrtko Ursulin (2019-07-22 12:41:36)
>>
>> On 20/07/2019 15:31, Chris Wilson wrote:
>> > Enabling atomic operations in L3 leads to unrecoverable GPU hangs, as
>> > the machine stops responding milliseconds after receipt of the reset
>> > request [GDRT]. By disablin
commit
code)
[1] https://lkml.org/lkml/2018/7/30/880
> Reviewed-by: Mika Kuoppala
>
> On other way around, the atomic commit code on updating
> planes, could potentially benefit of changing to the
> io_schedule_timeout. (and/or adopting c state limits)
>
> -Mika
>
>>
Chris Wilson writes:
> Quoting Francisco Jerez (2018-07-29 20:29:42)
>> Chris Wilson writes:
>>
>> > Quoting Francisco Jerez (2018-07-28 21:18:50)
>> >> Chris Wilson writes:
>> >>
>> >> > Quoting Francisco Jerez (2018-07-28
Chris Wilson writes:
> Quoting Francisco Jerez (2018-07-28 21:18:50)
>> Chris Wilson writes:
>>
>> > Quoting Francisco Jerez (2018-07-28 06:20:12)
>> >> Chris Wilson writes:
>> >>
>> >> > A recent trend for cpufreq is to boos
Chris Wilson writes:
> Quoting Francisco Jerez (2018-07-28 06:20:12)
>> Chris Wilson writes:
>>
>> > A recent trend for cpufreq is to boost the CPU frequencies for
>> > iowaiters, in particularly to benefit high frequency I/O. We do the same
>> > an
I think
the offending patch should probably be reverted for the time being...
[1] https://patchwork.kernel.org/patch/10312259/
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> Cc: Eero Tamminen
> Cc: Francisco Jerez
> ---
> drivers/gpu/drm/i91
Hey Chris,
Chris Wilson writes:
> I have to ask, if this is all just to work around iowait triggering high
> frequencies for GPU bound applications, does it all just boil down to
> i915 incorrectly using iowait. Does this patch set perform better than
>
> diff --git a/drivers/gpu/drm/i915/i915_r
Hi Srinivas,
Srinivas Pandruvada writes:
> On Wed, 2018-04-11 at 09:26 -0700, Francisco Jerez wrote:
>>
>> "just like" here is possibly somewhat unfair to the schedutil
>> governor,
>> admittedly its progressive IOWAIT boosting behavior seems somewhat
>
Peter Zijlstra writes:
> On Thu, Apr 12, 2018 at 12:55:39PM -0700, Francisco Jerez wrote:
>> Actually assuming that a single geometric feature of the power curve is
>> known -- it being convex in the frequency range allowed by the policy
>> (which is almost always the cas
Juri Lelli writes:
> Hi,
>
> On 11/04/18 09:26, Francisco Jerez wrote:
>> Francisco Jerez writes:
>>
>> > Hi Srinivas,
>> >
>> > Srinivas Pandruvada writes:
>> >
>> >> On Tue, 2018-04-10
Peter Zijlstra writes:
> On Thu, Apr 12, 2018 at 11:34:54AM -0700, Francisco Jerez wrote:
>> The reason for the energy efficiency problem of iowait boosting is
>> precisely the greater oscillation between turbo and idle. Say that
>> iowait boost increases the freque
Peter Zijlstra writes:
> On Wed, Apr 11, 2018 at 09:26:11AM -0700, Francisco Jerez wrote:
>> "just like" here is possibly somewhat unfair to the schedutil governor,
>> admittedly its progressive IOWAIT boosting behavior seems somewhat less
>> wasteful than the
Francisco Jerez writes:
> Hi Srinivas,
>
> Srinivas Pandruvada writes:
>
>> On Tue, 2018-04-10 at 15:28 -0700, Francisco Jerez wrote:
>>> Francisco Jerez writes:
>>>
>> [...]
>>
>>
>>> For the case anyone is wondering what'
Hi Srinivas,
Srinivas Pandruvada writes:
> On Tue, 2018-04-10 at 15:28 -0700, Francisco Jerez wrote:
>> Francisco Jerez writes:
>>
> [...]
>
>
>> For the case anyone is wondering what's going on, Srinivas pointed me
>> at
>> a larger idle powe
Francisco Jerez writes:
> This series attempts to solve an energy efficiency problem of the
> current active-mode non-HWP governor of the intel_pstate driver used
> for the most part on low-power platforms. Under heavy IO load the
> current controller tends to increase freque
of sequence points we can then
> expand on for further bookkeeping.
>
> v2: Refactor guc submission to share the same begin/end.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Francisco Jerez
> Reviewed-by: Francisco Jerez #v1
Thanks, v2 is also:
Reviewed-by
Francisco Jerez writes:
> This series attempts to solve an energy efficiency problem of the
> current active-mode non-HWP governor of the intel_pstate driver used
> for the most part on low-power platforms. Under heavy IO load the
> current controller tends to increase freque
of sequence points we can then
> expand on for further bookkeeping.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Francisco Jerez
> ---
> drivers/gpu/drm/i915/intel_lrc.c| 42
> -
> drivers/gpu/drm/i915/intel_ringbuf
Chris Wilson writes:
> Quoting Chris Wilson (2018-03-28 20:20:19)
>> Quoting Francisco Jerez (2018-03-28 19:55:12)
>> > Hi Chris,
>> >
>> [snip]
>> > That said, it wouldn't hurt to call each of them once per sequence of
>> >
Hi Chris,
Chris Wilson writes:
> Quoting Francisco Jerez (2018-03-28 07:38:45)
>> This allows cpufreq governors to realize when the system becomes
>> non-CPU-bound due to GPU rendering activity, which will cause the
>> intel_pstate LP controller to behave more conse
This reverts commit c4f3f70cacba2fa19545389a12d09b606d2ad1cf. A
future commit will introduce a new update_util implementation, so the
pstate_funcs table entry is going to be useful.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 15 +--
1 file changed, 13
an be forcefully enabled or disabled by passing
"intel_pstate=lp" or "intel_pstate=no_lp" respectively in the kernel
command line.
Signed-off-by: Francisco Jerez
---
Documentation/admin-guide/kernel-parameters.txt | 6 +
Documentation/admin-guide/pm/intel_pstate.rst |
roach
provides a more accurate estimate (while the alternative approach
would be biased towards 0% and would likely result in less
energy-efficient behavior of the cpufreq governor).
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/cpufreq.c | 204 ++
in
This series attempts to solve an energy efficiency problem of the
current active-mode non-HWP governor of the intel_pstate driver used
for the most part on low-power platforms. Under heavy IO load the
current controller tends to increase frequencies to the maximum turbo
P-state, partly due to IO w
shouldn't have any effect on other
systems.
Signed-off-by: Francisco Jerez
---
drivers/gpu/drm/i915/intel_lrc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3a69b367e565..721f915115bd 100644
--- a/drive
.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index fe847d086926..e21645f0fd3a 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers
the right pstate_funcs table
(at your own risk).
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 357 -
1 file changed, 353 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index ef
This reverts commit dbd49b85eec7eb6d7ae61bad8306d5cdd85c142d. A
future commit will introduce a new update_util implementation for LP
platforms, so the bxt_funcs table comes in handy.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 13 +++--
1 file changed, 11
,
.io_active_avg_hz = 10
}
A warning is printed out which should taint the kernel for the
non-standard calibration of the heuristic to be obvious in bug
reports.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 90 ++
1 file changed, 90 insertions
This reverts commit a891283e56362543d1d276e192266069ef52075b. The
previous approach of taking an explicit P-state target as argument
makes it more easily reusable by a future commit.
Signed-off-by: Francisco Jerez
---
drivers/cpufreq/intel_pstate.c | 12 +++-
1 file changed, 7
Chris Wilson writes:
> Quoting Francisco Jerez (2017-05-04 21:59:44)
>> Chris Wilson writes:
>>
>> > On Thu, May 04, 2017 at 10:56:54AM -0700, Francisco Jerez wrote:
>> >> David Weinehall writes:
>> >>
>> >> > On Thu, May 04
Chris Wilson writes:
> On Thu, May 04, 2017 at 10:56:54AM -0700, Francisco Jerez wrote:
>> David Weinehall writes:
>>
>> > On Thu, May 04, 2017 at 10:51:29AM +0100, Chris Wilson wrote:
>> >> A good default for garbage entries from the user is to follow the
David Weinehall writes:
> On Thu, May 04, 2017 at 10:51:29AM +0100, Chris Wilson wrote:
>> A good default for garbage entries from the user is to follow the
>> default setting of the object (i.e. the PTE). Currently they use the
>> uncached entry, and now the only way to accidentally hit uncached
Hi David,
David Weinehall writes:
> Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs.
> Some of these are used by media-sdk; if these entries are missing
> the default will instead be to do everything uncached.
>
Keep in mind that MOCS entries are not for free -- Once you
Daniel Vetter writes:
> On Wed, Jan 11, 2017 at 12:24:59PM +, Chris Wilson wrote:
>> On Wed, Jan 11, 2017 at 02:07:37PM +0200, Mika Kuoppala wrote:
>> > Daniel Vetter writes:
>> >
>> > > On Mon, Jan 09, 2017 at 01:07:56PM -0800, Francisco Jerez wrote
1 - 100 of 152 matches
Mail list logo
