Re: [PATCH 2/2] PM / devfreq: Generic cpufreq governor

On 05/27/2018 11:00 PM, MyungJoo Ham wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor performance and power. The same idea applies for

Re: [PATCH 2/2] PM / devfreq: Generic cpufreq governor

On 05/27/2018 11:00 PM, MyungJoo Ham wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor performance and power. The same idea applies for

Re: [PATCH 2/2] sched/fair: util_est: add running_sum tracking

On 06/05/2018 01:46 PM, Joel Fernandes wrote: On Tue, Jun 05, 2018 at 05:54:31PM +0100, Patrick Bellasi wrote: On 05-Jun 17:31, Juri Lelli wrote: On 05/06/18 16:11, Patrick Bellasi wrote: [...] If I run an experiment with your example above, while using the performance governor to rule out

Re: [PATCH 2/2] sched/fair: util_est: add running_sum tracking

On 06/05/2018 01:46 PM, Joel Fernandes wrote: On Tue, Jun 05, 2018 at 05:54:31PM +0100, Patrick Bellasi wrote: On 05-Jun 17:31, Juri Lelli wrote: On 05/06/18 16:11, Patrick Bellasi wrote: [...] If I run an experiment with your example above, while using the performance governor to rule out

Re: [PATCH 2/2] PM / devfreq: Generic cpufreq governor

Chanwoo, Friendly reminder for a review. I've addressed your comments on v1 of this patch. -Saravana On 05/18/2018 01:24 AM, Saravana Kannan wrote: This devfreq governor is a generic implementation that can scale any devfreq device based on the current CPU frequency of all ONLINE CPUs

Re: [PATCH 2/2] PM / devfreq: Generic cpufreq governor

Chanwoo, Friendly reminder for a review. I've addressed your comments on v1 of this patch. -Saravana On 05/18/2018 01:24 AM, Saravana Kannan wrote: This devfreq governor is a generic implementation that can scale any devfreq device based on the current CPU frequency of all ONLINE CPUs

Re: [PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware

On 05/22/2018 11:08 AM, Rob Herring wrote: On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote: The firmware present in some QCOM chipsets offloads the steps necessary for changing the frequency of some devices (Eg: L3). This driver implements the devfreq interface for this firmware

Re: [PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware

On 05/22/2018 11:08 AM, Rob Herring wrote: On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote: The firmware present in some QCOM chipsets offloads the steps necessary for changing the frequency of some devices (Eg: L3). This driver implements the devfreq interface for this firmware

Re: [PATCH v2] schedutil: Allow cpufreq requests to be made even when kthread kicked

On 05/18/2018 11:55 AM, Joel Fernandes (Google.) wrote: From: "Joel Fernandes (Google)" Currently there is a chance of a schedutil cpufreq update request to be dropped if there is a pending update request. This pending request can be delayed if there is a scheduling

Re: [PATCH v2] schedutil: Allow cpufreq requests to be made even when kthread kicked

On 05/18/2018 11:55 AM, Joel Fernandes (Google.) wrote: From: "Joel Fernandes (Google)" Currently there is a chance of a schedutil cpufreq update request to be dropped if there is a pending update request. This pending request can be delayed if there is a scheduling delay of the irq_work and

[PATCH 1/2] Revert "cpufreq: Remove policy create/remove notifiers"

This reverts commit f9f41e3ef99ac9d4e91b07634362e393fb929aad. Change-Id: Iddde3ef56c9e5b14dcb14f8737899b85e56f5b43 --- drivers/cpufreq/cpufreq.c | 16 +++- include/linux/cpufreq.h | 3 +++ 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c

[PATCH 1/2] Revert "cpufreq: Remove policy create/remove notifiers"

This reverts commit f9f41e3ef99ac9d4e91b07634362e393fb929aad. Change-Id: Iddde3ef56c9e5b14dcb14f8737899b85e56f5b43 --- drivers/cpufreq/cpufreq.c | 16 +++- include/linux/cpufreq.h | 3 +++ 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c

[PATCH 2/2] PM / devfreq: Generic cpufreq governor

in proportion to the CPU frequency. Change-Id: I7f786b9059435afe85b9ec8c504a4655731ee20e Signed-off-by: Saravana Kannan <skan...@codeaurora.org> --- .../bindings/devfreq/devfreq-cpufreq.txt | 53 ++ drivers/devfreq/Kconfig| 8 + drivers/devfreq/Ma

[PATCH 2/2] PM / devfreq: Generic cpufreq governor

in proportion to the CPU frequency. Change-Id: I7f786b9059435afe85b9ec8c504a4655731ee20e Signed-off-by: Saravana Kannan --- .../bindings/devfreq/devfreq-cpufreq.txt | 53 ++ drivers/devfreq/Kconfig| 8 + drivers/devfreq/Makefile | 1

[PATCH 0/2] Adding support for scaling cache/memory based on CPU frequency

in between. Since CPUs/clusters can be hotplugged and their policies disables, this devfreq governor also has to listen to CPU freq policy notifiers for these events. So, this patch brings back the policy CREATE/REMOVE notifiers. Saravana Kannan (2): Revert "cpufreq: Remove policy create/r

[PATCH 0/2] Adding support for scaling cache/memory based on CPU frequency

in between. Since CPUs/clusters can be hotplugged and their policies disables, this devfreq governor also has to listen to CPU freq policy notifiers for these events. So, this patch brings back the policy CREATE/REMOVE notifiers. Saravana Kannan (2): Revert "cpufreq: Remove policy create/r

[PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware

and cluster 1) that wants to vote for a particular device's frequency (say, L3 frequency) is represented as a separate voter device (qcom,devfreq-fw-voter) that's a child of the firmware device (qcom,devfreq-fw). Signed-off-by: Saravana Kannan <skan...@codeaurora.org> --- .../bindings/d

[PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware

and cluster 1) that wants to vote for a particular device's frequency (say, L3 frequency) is represented as a separate voter device (qcom,devfreq-fw-voter) that's a child of the firmware device (qcom,devfreq-fw). Signed-off-by: Saravana Kannan --- .../bindings/devfreq/devfreq-qcom-fw.txt

Re: [v0 2/2] cpufreq: qcom-fw: Add support for QCOM cpufreq FW driver

On 05/17/2018 03:14 AM, Viresh Kumar wrote: On 17-05-18, 15:00, Taniya Das wrote: The CPUfreq FW present in some QCOM chipsets offloads the steps necessary for hanging the frequency of CPUs. The driver implements the cpufreq driver interface for this firmware. Signed-off-by: Taniya Das

Re: [v0 2/2] cpufreq: qcom-fw: Add support for QCOM cpufreq FW driver

On 05/17/2018 03:14 AM, Viresh Kumar wrote: On 17-05-18, 15:00, Taniya Das wrote: The CPUfreq FW present in some QCOM chipsets offloads the steps necessary for hanging the frequency of CPUs. The driver implements the cpufreq driver interface for this firmware. Signed-off-by: Taniya Das ---

Re: [v0 1/2] dt-bindings: clock: Introduce QCOM CPUFREQ FW bindings

On 05/17/2018 03:14 AM, Viresh Kumar wrote: + Rob. On 17-05-18, 15:00, Taniya Das wrote: Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's SoCs. This is required for managing the cpu frequency transitions which are controlled by firmware. Signed-off-by: Taniya Das

Re: [v0 1/2] dt-bindings: clock: Introduce QCOM CPUFREQ FW bindings

On 05/17/2018 03:14 AM, Viresh Kumar wrote: + Rob. On 17-05-18, 15:00, Taniya Das wrote: Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's SoCs. This is required for managing the cpu frequency transitions which are controlled by firmware. Signed-off-by: Taniya Das ---

Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"

On 05/12/2018 10:19 PM, Joel Fernandes wrote: On Tue, May 08, 2018 at 10:42:37AM +0100, Quentin Perret wrote: On Tuesday 08 May 2018 at 11:09:57 (+0200), Dietmar Eggemann wrote: On 05/08/2018 10:22 AM, Viresh Kumar wrote: On 08-05-18, 08:33, Dietmar Eggemann wrote: This reverts commit

Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"

On 05/12/2018 10:19 PM, Joel Fernandes wrote: On Tue, May 08, 2018 at 10:42:37AM +0100, Quentin Perret wrote: On Tuesday 08 May 2018 at 11:09:57 (+0200), Dietmar Eggemann wrote: On 05/08/2018 10:22 AM, Viresh Kumar wrote: On 08-05-18, 08:33, Dietmar Eggemann wrote: This reverts commit

[PATCH] PM / devfreq: Add support for QCOM devfreq FW

The firmware present in some QCOM chipsets offloads the steps necessary for changing the frequency of some devices (Eg: L3). This driver implements the devfreq interface for this firmware so that various governors could be used to scale the frequency of these devices. Signed-off-by: Saravana

[PATCH] PM / devfreq: Add support for QCOM devfreq FW

The firmware present in some QCOM chipsets offloads the steps necessary for changing the frequency of some devices (Eg: L3). This driver implements the devfreq interface for this firmware so that various governors could be used to scale the frequency of these devices. Signed-off-by: Saravana

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/09/2018 05:35 AM, Mark Rutland wrote: On Fri, Mar 09, 2018 at 10:53:14AM +, Suzuki K Poulose wrote: + Cc: Lorenzo, Charles. On 08/03/18 23:59, Saravana Kannan wrote: On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/09/2018 05:35 AM, Mark Rutland wrote: On Fri, Mar 09, 2018 at 10:53:14AM +, Suzuki K Poulose wrote: + Cc: Lorenzo, Charles. On 08/03/18 23:59, Saravana Kannan wrote: On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit (DSU). The DSU integrates one or more cores with an L3 memory system, control logic, and external interfaces to form a multicore cluster. The PMU allows counting the various events

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit (DSU). The DSU integrates one or more cores with an L3 memory system, control logic, and external interfaces to form a multicore cluster. The PMU allows counting the various events

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/07/2018 06:59 AM, Suzuki K Poulose wrote: Hi Saravana, Sorry for the late response, I was out on vacation. On 05/03/18 22:10, Saravana Kannan wrote: On 03/05/2018 02:59 AM, Mark Rutland wrote: On Fri, Mar 02, 2018 at 11:19:56AM -0800, Saravana Kannan wrote: On 03/02/2018 02:42 AM

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/07/2018 06:59 AM, Suzuki K Poulose wrote: Hi Saravana, Sorry for the late response, I was out on vacation. On 05/03/18 22:10, Saravana Kannan wrote: On 03/05/2018 02:59 AM, Mark Rutland wrote: On Fri, Mar 02, 2018 at 11:19:56AM -0800, Saravana Kannan wrote: On 03/02/2018 02:42 AM

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/05/2018 02:59 AM, Mark Rutland wrote: On Fri, Mar 02, 2018 at 11:19:56AM -0800, Saravana Kannan wrote: On 03/02/2018 02:42 AM, Mark Rutland wrote: It's important to note that the DSU PMU's event_init() ensures events are affine to a single CPU, and the perf core code serializes

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/05/2018 02:59 AM, Mark Rutland wrote: On Fri, Mar 02, 2018 at 11:19:56AM -0800, Saravana Kannan wrote: On 03/02/2018 02:42 AM, Mark Rutland wrote: It's important to note that the DSU PMU's event_init() ensures events are affine to a single CPU, and the perf core code serializes

Re: [PATCH v2] perf/core: Add support for PMUs that can be read from more than 1 CPU

On 03/05/2018 04:17 AM, Mark Rutland wrote: On Fri, Mar 02, 2018 at 05:14:53PM -0800, Saravana Kannan wrote: Some PMUs events can be read from more than the one CPU. So allow the PMU driver to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's

Re: [PATCH v2] perf/core: Add support for PMUs that can be read from more than 1 CPU

On 03/05/2018 04:17 AM, Mark Rutland wrote: On Fri, Mar 02, 2018 at 05:14:53PM -0800, Saravana Kannan wrote: Some PMUs events can be read from more than the one CPU. So allow the PMU driver to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's

Re: [PATCH v2] perf/core: Add support for PMUs that can be read from more than 1 CPU

On 03/05/2018 04:21 AM, Mark Rutland wrote: On Mon, Mar 05, 2018 at 12:17:02PM +, Mark Rutland wrote: On Fri, Mar 02, 2018 at 05:14:53PM -0800, Saravana Kannan wrote: @@ -629,6 +629,7 @@ struct perf_event { int oncpu; int

Re: [PATCH v2] perf/core: Add support for PMUs that can be read from more than 1 CPU

On 03/05/2018 04:21 AM, Mark Rutland wrote: On Mon, Mar 05, 2018 at 12:17:02PM +, Mark Rutland wrote: On Fri, Mar 02, 2018 at 05:14:53PM -0800, Saravana Kannan wrote: @@ -629,6 +629,7 @@ struct perf_event { int oncpu; int

[PATCH v2] perf/core: Add support for PMUs that can be read from more than 1 CPU

. Signed-off-by: Saravana Kannan <skan...@codeaurora.org> --- Changes since v1: - Use cpumasks instead of capability flag as that's more flexible. include/linux/perf_event.h | 1 + kernel/events/core.c | 14 +- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/i

[PATCH v2] perf/core: Add support for PMUs that can be read from more than 1 CPU

. Signed-off-by: Saravana Kannan --- Changes since v1: - Use cpumasks instead of capability flag as that's more flexible. include/linux/perf_event.h | 1 + kernel/events/core.c | 14 +- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/include/linux/perf_event.h b

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/02/2018 02:42 AM, Mark Rutland wrote: On Thu, Mar 01, 2018 at 12:35:49PM -0800, Saravana Kannan wrote: On 03/01/2018 03:49 AM, Mark Rutland wrote: On Wed, Feb 28, 2018 at 02:17:33PM -0800, Saravana Kannan wrote: On 02/25/2018 06:36 AM, Mark Rutland wrote: On Fri, Feb 23, 2018 at 04:53

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/02/2018 02:42 AM, Mark Rutland wrote: On Thu, Mar 01, 2018 at 12:35:49PM -0800, Saravana Kannan wrote: On 03/01/2018 03:49 AM, Mark Rutland wrote: On Wed, Feb 28, 2018 at 02:17:33PM -0800, Saravana Kannan wrote: On 02/25/2018 06:36 AM, Mark Rutland wrote: On Fri, Feb 23, 2018 at 04:53

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/01/2018 03:49 AM, Mark Rutland wrote: On Wed, Feb 28, 2018 at 02:17:33PM -0800, Saravana Kannan wrote: On 02/25/2018 06:36 AM, Mark Rutland wrote: On Fri, Feb 23, 2018 at 04:53:18PM -0800, Saravana Kannan wrote: On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: +static void

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 03/01/2018 03:49 AM, Mark Rutland wrote: On Wed, Feb 28, 2018 at 02:17:33PM -0800, Saravana Kannan wrote: On 02/25/2018 06:36 AM, Mark Rutland wrote: On Fri, Feb 23, 2018 at 04:53:18PM -0800, Saravana Kannan wrote: On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: +static void

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 02/25/2018 06:36 AM, Mark Rutland wrote: On Fri, Feb 23, 2018 at 04:53:18PM -0800, Saravana Kannan wrote: On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: +static void dsu_pmu_event_update(struct perf_event *event) +{ + struct hw_perf_event *hwc = >hw; + u64 delta, prev_co

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 02/25/2018 06:36 AM, Mark Rutland wrote: On Fri, Feb 23, 2018 at 04:53:18PM -0800, Saravana Kannan wrote: On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: +static void dsu_pmu_event_update(struct perf_event *event) +{ + struct hw_perf_event *hwc = >hw; + u64 delta, prev_co

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 02/23/2018 04:19 PM, Saravana Kannan wrote: Some PMUs events can be read from any CPU. So allow the PMU to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's CPU and cause unnecessary wake ups. Good examples of such events would be events

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 02/23/2018 04:19 PM, Saravana Kannan wrote: Some PMUs events can be read from any CPU. So allow the PMU to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's CPU and cause unnecessary wake ups. Good examples of such events would be events

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit (DSU). The DSU integrates one or more cores with an L3 memory system, control logic, and external interfaces to form a multicore cluster. The PMU allows counting the various events

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit (DSU). The DSU integrates one or more cores with an L3 memory system, control logic, and external interfaces to form a multicore cluster. The PMU allows counting the various events

[PATCH v1 1/2] perf/core: Add API to look up PMU type by name

way for a kernel client to look up the PMU type for the PMU of interest and set the attr->type appropriately. So, add an API to look up the PMU type by name. That way, the kernel APIs can function in a fashion similar to the user space interface. Signed-off-by: Saravana Kannan <skan...@codea

[PATCH v1 1/2] perf/core: Add API to look up PMU type by name

way for a kernel client to look up the PMU type for the PMU of interest and set the attr->type appropriately. So, add an API to look up the PMU type by name. That way, the kernel APIs can function in a fashion similar to the user space interface. Signed-off-by: Saravana Kannan --- kernel/events/core.

[PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

-by: Saravana Kannan <skan...@codeaurora.org> --- include/linux/perf_event.h | 3 +++ kernel/events/core.c | 10 -- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index 7546822..ee8978f 100644 --- a/include

[PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

-by: Saravana Kannan --- include/linux/perf_event.h | 3 +++ kernel/events/core.c | 10 -- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h index 7546822..ee8978f 100644 --- a/include/linux/perf_event.h +++ b/include

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 02/23/2018 03:35 AM, Mark Rutland wrote: On Thu, Feb 22, 2018 at 12:38:39PM -0800, Saravana Kannan wrote: On 02/22/2018 03:33 AM, Mark Rutland wrote: On Wed, Feb 21, 2018 at 06:32:46PM -0800, Saravana Kannan wrote: I'm not exactly sure if we can add entries to perf_type_id. If that's

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 02/23/2018 03:35 AM, Mark Rutland wrote: On Thu, Feb 22, 2018 at 12:38:39PM -0800, Saravana Kannan wrote: On 02/22/2018 03:33 AM, Mark Rutland wrote: On Wed, Feb 21, 2018 at 06:32:46PM -0800, Saravana Kannan wrote: I'm not exactly sure if we can add entries to perf_type_id. If that's

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 02/22/2018 03:33 AM, Mark Rutland wrote: On Wed, Feb 21, 2018 at 06:32:46PM -0800, Saravana Kannan wrote: On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: +static int dsu_pmu_event_init(struct perf_event *event) +{ + struct dsu_pmu *dsu_pmu = to_dsu_pmu(event->pmu); + + if (ev

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 02/22/2018 03:33 AM, Mark Rutland wrote: On Wed, Feb 21, 2018 at 06:32:46PM -0800, Saravana Kannan wrote: On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: +static int dsu_pmu_event_init(struct perf_event *event) +{ + struct dsu_pmu *dsu_pmu = to_dsu_pmu(event->pmu); + + if (ev

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit (DSU). The DSU integrates one or more cores with an L3 memory system, control logic, and external interfaces to form a multicore cluster. The PMU allows counting the various events

Re: [PATCH v11 8/8] perf: ARM DynamIQ Shared Unit PMU support

On 01/02/2018 03:25 AM, Suzuki K Poulose wrote: Add support for the Cluster PMU part of the ARM DynamIQ Shared Unit (DSU). The DSU integrates one or more cores with an L3 memory system, control logic, and external interfaces to form a multicore cluster. The PMU allows counting the various events

Re: [PATCH] cpufreq: skip cpufreq resume if it's not suspended

On 02/05/2018 01:05 AM, Viresh Kumar wrote: On 05-02-18, 09:50, Rafael J. Wysocki wrote: By design (which I admit may be confusing) it should be fine to call dpm_resume_end() after a failing dpm_suspend_start(), whatever the reason for the failure is. cpufreq_suspend/resume() don't take that

Re: [PATCH] cpufreq: skip cpufreq resume if it's not suspended

On 02/05/2018 01:05 AM, Viresh Kumar wrote: On 05-02-18, 09:50, Rafael J. Wysocki wrote: By design (which I admit may be confusing) it should be fine to call dpm_resume_end() after a failing dpm_suspend_start(), whatever the reason for the failure is. cpufreq_suspend/resume() don't take that

Re: [PATCH] cpufreq: skip cpufreq resume if it's not suspended

On 02/02/2018 03:54 AM, Rafael J. Wysocki wrote: On Wednesday, January 24, 2018 9:53:14 PM CET Bo Yan wrote: On 01/23/2018 06:02 PM, Rafael J. Wysocki wrote: On Tuesday, January 23, 2018 10:57:55 PM CET Bo Yan wrote: drivers/cpufreq/cpufreq.c | 4 1 file changed, 4 insertions(+)

Re: [PATCH] cpufreq: skip cpufreq resume if it's not suspended

On 02/02/2018 03:54 AM, Rafael J. Wysocki wrote: On Wednesday, January 24, 2018 9:53:14 PM CET Bo Yan wrote: On 01/23/2018 06:02 PM, Rafael J. Wysocki wrote: On Tuesday, January 23, 2018 10:57:55 PM CET Bo Yan wrote: drivers/cpufreq/cpufreq.c | 4 1 file changed, 4 insertions(+)

Re: [PATCH] devfreq: add error check for sscanf in userspace governor

On 08/07/2017 11:56 PM, Pavan Kondeti wrote: Hi Santosh, On Mon, Aug 7, 2017 at 6:36 PM, Santosh Mardi wrote: store_freq function of devfreq userspace governor executes further, even if error is returned from sscanf, this will result in setting up wrong frequency

Re: [PATCH] devfreq: add error check for sscanf in userspace governor

On 08/07/2017 11:56 PM, Pavan Kondeti wrote: Hi Santosh, On Mon, Aug 7, 2017 at 6:36 PM, Santosh Mardi wrote: store_freq function of devfreq userspace governor executes further, even if error is returned from sscanf, this will result in setting up wrong frequency value. Add proper error

Re: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

* - the local and remote CPUs share cpufreq policy +*/ + if (policy->dvfs_possible_from_any_cpu || + cpumask_test_cpu(smp_processor_id(), policy->cpus)) return true; return false; Acked-by: Saravana Kannan <skan...@codeaurora.org> -- Qual

Re: [PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

e cpufreq policy +*/ + if (policy->dvfs_possible_from_any_cpu || + cpumask_test_cpu(smp_processor_id(), policy->cpus)) return true; return false; Acked-by: Saravana Kannan -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, I

Re: [PATCH V5 1/2] sched: cpufreq: Allow remote cpufreq callbacks

(struct rq *rq, unsigned int flags) {} -static inline void cpufreq_update_this_cpu(struct rq *rq, unsigned int flags) {} #endif /* CONFIG_CPU_FREQ */ #ifdef arch_scale_freq_capacity Acked-by: Saravana Kannan <skan...@codeaurora.org> -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH V5 1/2] sched: cpufreq: Allow remote cpufreq callbacks

lags) {} -static inline void cpufreq_update_this_cpu(struct rq *rq, unsigned int flags) {} #endif /* CONFIG_CPU_FREQ */ #ifdef arch_scale_freq_capacity Acked-by: Saravana Kannan -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/27/2017 11:00 PM, Viresh Kumar wrote: On 27-07-17, 12:55, Saravana Kannan wrote: Yes. Simplifying isn't always about number of lines of code. It's also about abstraction. Having generic scheduler code care about HW details doesn't seem nice. I can argue that even the policy->cpus fi

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/27/2017 11:00 PM, Viresh Kumar wrote: On 27-07-17, 12:55, Saravana Kannan wrote: Yes. Simplifying isn't always about number of lines of code. It's also about abstraction. Having generic scheduler code care about HW details doesn't seem nice. I can argue that even the policy->cpus fi

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/26/2017 08:30 PM, Viresh Kumar wrote: On 26-07-17, 14:00, Saravana Kannan wrote: No, the alternative is to pass it on to the CPU freq driver and let it decide what it wants to do. That's the whole point if having a CPU freq driver -- so that the generic code doesn't need to care about HW

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/26/2017 08:30 PM, Viresh Kumar wrote: On 26-07-17, 14:00, Saravana Kannan wrote: No, the alternative is to pass it on to the CPU freq driver and let it decide what it wants to do. That's the whole point if having a CPU freq driver -- so that the generic code doesn't need to care about HW

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/21/2017 06:03 AM, Peter Zijlstra wrote: On Thu, Jul 13, 2017 at 12:14:37PM +0530, Viresh Kumar wrote: diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index 47e24b5384b3..606b1a37a1af 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++

Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

On 07/21/2017 06:03 AM, Peter Zijlstra wrote: On Thu, Jul 13, 2017 at 12:14:37PM +0530, Viresh Kumar wrote: diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index 47e24b5384b3..606b1a37a1af 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++

Re: [Eas-dev] [PATCH V3 2/3] cpufreq: schedutil: Process remote callback for shared policies

On 07/20/2017 05:22 AM, Peter Zijlstra wrote: So the typical implementation of fast switching we're thinking of is the CPU writing the DVFS request into a machine register. Now machine registers are typically per logical CPU. Writing to a memory addressable register. AFAIK, ARM has no support

Re: [Eas-dev] [PATCH V3 2/3] cpufreq: schedutil: Process remote callback for shared policies

On 07/20/2017 05:22 AM, Peter Zijlstra wrote: So the typical implementation of fast switching we're thinking of is the CPU writing the DVFS request into a machine register. Now machine registers are typically per logical CPU. Writing to a memory addressable register. AFAIK, ARM has no support

Re: [Eas-dev] [PATCH V3 2/3] cpufreq: schedutil: Process remote callback for shared policies

On 07/12/2017 11:44 PM, Viresh Kumar wrote: This patch updates the schedutil governor to process cpufreq utilization update hooks called for remote CPUs. The schedutil governor already has proper locking in place for shared policy update hooks and nothing extra is required to be done. Based on

Re: [Eas-dev] [PATCH V3 2/3] cpufreq: schedutil: Process remote callback for shared policies

On 07/12/2017 11:44 PM, Viresh Kumar wrote: This patch updates the schedutil governor to process cpufreq utilization update hooks called for remote CPUs. The schedutil governor already has proper locking in place for shared policy update hooks and nothing extra is required to be done. Based on

Re: [PATCH] cpufreq: schedutil: Update cached "current frequency" when limits change

On 07/11/2017 10:24 PM, Viresh Kumar wrote: On 11-07-17, 19:24, Saravana Kannan wrote: Currently, the governor calculates the next frequency, set the current CPU frequency (policy->cur). It also assumes the current CPU frequency doesn't change if the next frequency isn't calculated ag

Re: [PATCH] cpufreq: schedutil: Update cached "current frequency" when limits change

On 07/11/2017 10:24 PM, Viresh Kumar wrote: On 11-07-17, 19:24, Saravana Kannan wrote: Currently, the governor calculates the next frequency, set the current CPU frequency (policy->cur). It also assumes the current CPU frequency doesn't change if the next frequency isn't calculated ag

Re: [PATCH] cpufreq: schedutil: Update cached "current frequency" when limits change

On 07/11/2017 10:24 PM, Viresh Kumar wrote: On 11-07-17, 19:24, Saravana Kannan wrote: Currently, the governor calculates the next frequency, set the current CPU frequency (policy->cur). It also assumes the current CPU frequency doesn't change if the next frequency isn't calculated ag

Re: [PATCH] cpufreq: schedutil: Update cached "current frequency" when limits change

On 07/11/2017 10:24 PM, Viresh Kumar wrote: On 11-07-17, 19:24, Saravana Kannan wrote: Currently, the governor calculates the next frequency, set the current CPU frequency (policy->cur). It also assumes the current CPU frequency doesn't change if the next frequency isn't calculated ag

[PATCH] cpufreq: schedutil: Update cached "current frequency" when limits change

max frequency limits are changed. So, there's room for the CPU frequency to get stuck at the wrong level if the calculated next frequency doesn't change across multiple limits updates. Fix this by updating the cached "current frequency" when limits changes the current CPU frequency.

[PATCH] cpufreq: schedutil: Update cached "current frequency" when limits change

max frequency limits are changed. So, there's room for the CPU frequency to get stuck at the wrong level if the calculated next frequency doesn't change across multiple limits updates. Fix this by updating the cached "current frequency" when limits changes the current CPU frequency.

Re: [PATCH v2 2/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On 07/07/2017 03:17 AM, Juri Lelli wrote: On 06/07/17 21:43, Joel Fernandes wrote: On Tue, Jul 4, 2017 at 10:34 AM, Patrick Bellasi wrote: [...] @@ -304,6 +304,12 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, sg_cpu->util =

Re: [PATCH v2 2/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On 07/07/2017 03:17 AM, Juri Lelli wrote: On 06/07/17 21:43, Joel Fernandes wrote: On Tue, Jul 4, 2017 at 10:34 AM, Patrick Bellasi wrote: [...] @@ -304,6 +304,12 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time, sg_cpu->util = util;

Re: [PATCH v2 1/6] cpufreq: schedutil: ignore sugov kthreads

On 07/04/2017 10:34 AM, Patrick Bellasi wrote: In system where multiple CPUs shares the same frequency domain a small workload on a CPU can still be subject to frequency spikes, generated by the activation of the sugov's kthread. Since the sugov kthread is a special RT task, which goal is just

Re: [PATCH v2 1/6] cpufreq: schedutil: ignore sugov kthreads

On 07/04/2017 10:34 AM, Patrick Bellasi wrote: In system where multiple CPUs shares the same frequency domain a small workload on a CPU can still be subject to frequency spikes, generated by the activation of the sugov's kthread. Since the sugov kthread is a special RT task, which goal is just

Re: [PATCH v2 2/2] sched: Make iowait_boost optional in schedutil

android. I don't feel strongly about one way or the other and if the general consensus is to drop this part then I'm fine. I'm curious to know what others think as well though. Acked-by: Saravana Kannan <skan...@codeaurora.org> -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Re: [PATCH v2 2/2] sched: Make iowait_boost optional in schedutil

to. This is also how we currently set the rate limits for schedutil in android. I don't feel strongly about one way or the other and if the general consensus is to drop this part then I'm fine. I'm curious to know what others think as well though. Acked-by: Saravana Kannan -- Qualcomm Innovatio

Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support

On 06/19/2017 11:17 PM, Viresh Kumar wrote: On Thu, Jun 8, 2017 at 1:25 PM, Dietmar Eggemann wrote: diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c static int __init register_cpufreq_notifier(void) { + int ret; + /*

Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support

On 06/19/2017 11:17 PM, Viresh Kumar wrote: On Thu, Jun 8, 2017 at 1:25 PM, Dietmar Eggemann wrote: diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c static int __init register_cpufreq_notifier(void) { + int ret; + /* * on ACPI-based

Re: [RFC v0 1/2] interconnect: Add generic interconnect controller API

On 03/01/2017 10:22 AM, Georgi Djakov wrote: This patch introduce a new API to get the requirement and configure the interconnect buses across the entire chipset to fit with the current demand. The API is using a consumer/provider-based model, where the providers are the interconnect

Re: [RFC v0 1/2] interconnect: Add generic interconnect controller API

On 03/01/2017 10:22 AM, Georgi Djakov wrote: This patch introduce a new API to get the requirement and configure the interconnect buses across the entire chipset to fit with the current demand. The API is using a consumer/provider-based model, where the providers are the interconnect

Re: [PATCH] timers: Fix timer inaccuracy

On 11/10/2016 02:07 AM, Thomas Gleixner wrote: On Wed, 9 Nov 2016, Joonwoo Park wrote: So this timer expired exactly a few micro seconds after arming and therefor violates the guarantee of firing not before the specified interval. So depending on when you arm the timer the expiry is going

Re: [PATCH] timers: Fix timer inaccuracy

On 11/10/2016 02:07 AM, Thomas Gleixner wrote: On Wed, 9 Nov 2016, Joonwoo Park wrote: So this timer expired exactly a few micro seconds after arming and therefor violates the guarantee of firing not before the specified interval. So depending on when you arm the timer the expiry is going

Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task

On 11/11/2016 02:16 PM, Rafael J. Wysocki wrote: On Fri, Nov 11, 2016 at 11:22 AM, Viresh Kumar wrote: If slow path frequency changes are conducted in a SCHED_OTHER context then they may be delayed for some amount of time, including indefinitely, when real time or

Re: [PATCH 2/3] cpufreq: schedutil: move slow path from workqueue to SCHED_FIFO task

On 11/11/2016 02:16 PM, Rafael J. Wysocki wrote: On Fri, Nov 11, 2016 at 11:22 AM, Viresh Kumar wrote: If slow path frequency changes are conducted in a SCHED_OTHER context then they may be delayed for some amount of time, including indefinitely, when real time or deadline activity is taking

<    4   5   6   7   8   9   10   11   12   13   >