All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Chanwoo Choi <cw00.choi@samsung.com>
Cc: andrew-sh.cheng@mediatek.com, hsinyi@chromium.org,
	sibis@codeaurora.org, saravanak@google.com,
	myungjoo.ham@samsung.com, kyungmin.park@samsung.com,
	chanwoo@kernel.org, cwchoi00@gmail.com, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Saravana Kannan <skannan@codeaurora.org>
Subject: Re: [PATCH 3/4] PM / devfreq: Add cpu based scaling support to passive governor
Date: Tue, 22 Jun 2021 10:42:35 -0700	[thread overview]
Message-ID: <YNIhCxw0bnweb9SB@google.com> (raw)
In-Reply-To: <20210617060546.26933-4-cw00.choi@samsung.com>

On Thu, Jun 17, 2021 at 03:05:45PM +0900, Chanwoo Choi wrote:
> From: Saravana Kannan <skannan@codeaurora.org>
> 
> Many CPU architectures have caches that can scale independent of the
> CPUs. Frequency scaling of the caches is necessary to make sure that the
> cache is not a performance bottleneck that leads to poor performance and
> power. The same idea applies for RAM/DDR.
> 
> To achieve this, this patch adds support for cpu based scaling to the
> passive governor. This is accomplished by taking the current frequency
> of each CPU frequency domain and then adjust the frequency of the cache
> (or any devfreq device) based on the frequency of the CPUs. It listens
> to CPU frequency transition notifiers to keep itself up to date on the
> current CPU frequency.
> 
> To decide the frequency of the device, the governor does one of the
> following:
> * Derives the optimal devfreq device opp from required-opps property of
>   the parent cpu opp_table.
> 
> * Scales the device frequency in proportion to the CPU frequency. So, if
>   the CPUs are running at their max frequency, the device runs at its
>   max frequency. If the CPUs are running at their min frequency, the
>   device runs at its min frequency. It is interpolated for frequencies
>   in between.
> 
> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
> [Sibi: Integrated cpu-freqmap governor into passive_governor]
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> [Chanwoo: Fix conflict with latest code and clean code up]
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
>  drivers/devfreq/governor.h         |  22 +++
>  drivers/devfreq/governor_passive.c | 264 ++++++++++++++++++++++++++++-
>  include/linux/devfreq.h            |  16 +-
>  3 files changed, 293 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
> index 9a9495f94ac6..3c36c92c89a9 100644
> --- a/drivers/devfreq/governor.h
> +++ b/drivers/devfreq/governor.h
> @@ -47,6 +47,28 @@
>  #define DEVFREQ_GOV_ATTR_POLLING_INTERVAL		BIT(0)
>  #define DEVFREQ_GOV_ATTR_TIMER				BIT(1)
>  
> +/**
> + * struct devfreq_cpu_data - Hold the per-cpu data
> + * @dev:	reference to cpu device.
> + * @first_cpu:	the cpumask of the first cpu of a policy.
> + * @opp_table:	reference to cpu opp table.
> + * @cur_freq:	the current frequency of the cpu.
> + * @min_freq:	the min frequency of the cpu.
> + * @max_freq:	the max frequency of the cpu.
> + *
> + * This structure stores the required cpu_data of a cpu.
> + * This is auto-populated by the governor.
> + */
> +struct devfreq_cpu_data {
> +	struct device *dev;
> +	unsigned int first_cpu;
> +
> +	struct opp_table *opp_table;
> +	unsigned int cur_freq;
> +	unsigned int min_freq;
> +	unsigned int max_freq;
> +};
> +
>  /**
>   * struct devfreq_governor - Devfreq policy governor
>   * @node:		list node - contains registered devfreq governors
> diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
> index fc09324a03e0..07e864509b7e 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
>
> ...
>
> +static int cpufreq_passive_register_notifier(struct devfreq *devfreq)
> +{
> +	struct devfreq_passive_data *p_data
> +			= (struct devfreq_passive_data *)devfreq->data;
> +	struct device *dev = devfreq->dev.parent;
> +	struct opp_table *opp_table = NULL;
> +	struct devfreq_cpu_data *cpu_data;
> +	struct cpufreq_policy *policy;
> +	struct device *cpu_dev;
> +	unsigned int cpu;
> +	int ret;
> +
> +	get_online_cpus();
> +
> +	p_data->nb.notifier_call = cpufreq_passive_notifier_call;
> +	ret = cpufreq_register_notifier(&p_data->nb, CPUFREQ_TRANSITION_NOTIFIER);
> +	if (ret) {
> +		dev_err(dev, "failed to register cpufreq notifier\n");
> +		p_data->nb.notifier_call = NULL;
> +		goto out;
> +	}
> +
> +	for_each_online_cpu(cpu) {


Is this really needed for each CPU? Wouldn't it be enough to create
a 'cpu_data' for each 'policy CPU'?

In any case should this be for_each_possible_cpu() as in _unregister_notifier()
to also support CPUs that may be offline when the notifier is registered?

> +		if (p_data->cpu_data[cpu])
> +			continue;
> +
> +		policy = cpufreq_cpu_get(cpu);
> +		if (policy) {
> +			cpu_data = kzalloc(sizeof(*cpu_data), GFP_KERNEL);
> +			if (!cpu_data) {
> +				ret = -ENOMEM;
> +				goto out;
> +			}
> +
> +			cpu_dev = get_cpu_device(cpu);
> +			if (!cpu_dev) {
> +				dev_err(dev, "failed to get cpu device\n");
> +				ret = -ENODEV;
> +				goto out;

Memory for 'cpu_data' is not freed in this path.

Also applies to CPUs from possible prior iterations.

> +			}
> +
> +			opp_table = dev_pm_opp_get_opp_table(cpu_dev);
> +			if (IS_ERR(opp_table)) {
> +				ret = PTR_ERR(opp_table);
> +				goto out;

Ditto and cpufreq_cpu_put() is missing too.

> +			}
> +
> +			cpu_data->dev = cpu_dev;
> +			cpu_data->opp_table = opp_table;
> +			cpu_data->first_cpu = cpumask_first(policy->related_cpus);
> +			cpu_data->cur_freq = policy->cur;
> +			cpu_data->min_freq = policy->cpuinfo.min_freq;
> +			cpu_data->max_freq = policy->cpuinfo.max_freq;
> +
> +			p_data->cpu_data[cpu] = cpu_data;
> +			cpufreq_cpu_put(policy);
> +		} else {
> +			ret = -EPROBE_DEFER;
> +			goto out;

Resources from possible prior iterations aren't freed.

> +		}
> +	}
> +out:
> +	put_online_cpus();
> +	if (ret)
> +		return ret;
> +
> +	mutex_lock(&devfreq->lock);
> +	ret = devfreq_update_target(devfreq, 0L);
> +	mutex_unlock(&devfreq->lock);
> +	if (ret)
> +		dev_err(dev, "failed to update the frequency\n");
> +
> +	return ret;
> +}
> +
> +static int cpufreq_passive_unregister_notifier(struct devfreq *devfreq)
> +{
> +	struct devfreq_passive_data *p_data
> +			= (struct devfreq_passive_data *)devfreq->data;
> +	struct devfreq_cpu_data *cpu_data;
> +	int cpu;
> +
> +	if (p_data->nb.notifier_call)
> +		cpufreq_unregister_notifier(&p_data->nb, CPUFREQ_TRANSITION_NOTIFIER);
> +
> +	for_each_possible_cpu(cpu) {
> +		cpu_data = p_data->cpu_data[cpu];
> +		if (cpu_data) {
> +			if (cpu_data->opp_table)
> +				dev_pm_opp_put_opp_table(cpu_data->opp_table);
> +			kfree(cpu_data);
> +			cpu_data = NULL;

Assignment to NULL is not needed.

> +		}
> +	}
> +
> +	return 0;
> +}
> +
>  static int devfreq_passive_notifier_call(struct notifier_block *nb,
>  				unsigned long event, void *ptr)
>  {
> @@ -140,7 +379,7 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
>  	struct notifier_block *nb = &p_data->nb;
>  	int ret = 0;
>  
> -	if (!parent)
> +	if (p_data->parent_type == DEVFREQ_PARENT_DEV && !parent)
>  		return -EPROBE_DEFER;
>  
>  	switch (event) {
> @@ -148,13 +387,24 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
>  		if (!p_data->this)
>  			p_data->this = devfreq;
>  
> -		nb->notifier_call = devfreq_passive_notifier_call;
> -		ret = devfreq_register_notifier(parent, nb,
> -					DEVFREQ_TRANSITION_NOTIFIER);
> +		if (p_data->parent_type == DEVFREQ_PARENT_DEV) {
> +			nb->notifier_call = devfreq_passive_notifier_call;
> +			ret = devfreq_register_notifier(parent, nb,
> +						DEVFREQ_TRANSITION_NOTIFIER);
> +		} else if (p_data->parent_type == CPUFREQ_PARENT_DEV) {
> +			ret = cpufreq_passive_register_notifier(devfreq);
> +		} else {
> +			ret = -EINVAL;
> +		}
>  		break;
>  	case DEVFREQ_GOV_STOP:
> -		WARN_ON(devfreq_unregister_notifier(parent, nb,
> -					DEVFREQ_TRANSITION_NOTIFIER));
> +		if (p_data->parent_type == DEVFREQ_PARENT_DEV)
> +			WARN_ON(devfreq_unregister_notifier(parent, nb,
> +						DEVFREQ_TRANSITION_NOTIFIER));
> +		else if (p_data->parent_type == CPUFREQ_PARENT_DEV)
> +			WARN_ON(cpufreq_passive_unregister_notifier(devfreq));
> +		else
> +			ret = -EINVAL;
>  		break;
>  	default:
>  		break;
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index 142474b4af96..cfa0ef54841e 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -38,6 +38,7 @@ enum devfreq_timer {
>  
>  struct devfreq;
>  struct devfreq_governor;
> +struct devfreq_cpu_data;
>  struct thermal_cooling_device;
>  
>  /**
> @@ -288,6 +289,11 @@ struct devfreq_simple_ondemand_data {
>  #endif
>  
>  #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
> +enum devfreq_parent_dev_type {
> +	DEVFREQ_PARENT_DEV,
> +	CPUFREQ_PARENT_DEV,
> +};
> +
>  /**
>   * struct devfreq_passive_data - ``void *data`` fed to struct devfreq
>   *	and devfreq_add_device
> @@ -299,8 +305,10 @@ struct devfreq_simple_ondemand_data {
>   *			using governors except for passive governor.
>   *			If the devfreq device has the specific method to decide
>   *			the next frequency, should use this callback.
> - * @this:	the devfreq instance of own device.
> - * @nb:		the notifier block for DEVFREQ_TRANSITION_NOTIFIER list
> + + * @parent_type	parent type of the device
> + + * @this:		the devfreq instance of own device.
> + + * @nb:		the notifier block for DEVFREQ_TRANSITION_NOTIFIER list
> + + * @cpu_data:		the state min/max/current frequency of all online cpu's
>   *
>   * The devfreq_passive_data have to set the devfreq instance of parent
>   * device with governors except for the passive governor. But, don't need to
> @@ -314,9 +322,13 @@ struct devfreq_passive_data {
>  	/* Optional callback to decide the next frequency of passvice device */
>  	int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
>  
> +	/* Should set the type of parent device */
> +	enum devfreq_parent_dev_type parent_type;
> +
>  	/* For passive governor's internal use. Don't need to set them */
>  	struct devfreq *this;
>  	struct notifier_block nb;
> +	struct devfreq_cpu_data *cpu_data[NR_CPUS];

Could memory usage be a concern on systems with a really high number of CPUs
(e.g. 8k for x86 with MAXSMP)? One could argue that such systems likely have
significant amount of RAM too and a chunk of memory in the order of 100k
wouldn't make a big impact. I'm assuming that 'cpu_data' is only needed for
'policy CPUs'.

  parent reply	other threads:[~2021-06-22 17:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210617054647epcas1p3f1ef3ddef736496151ff77df4f50749a@epcas1p3.samsung.com>
2021-06-17  6:05 ` [PATCH 0/4] PM / devfreq: Add cpu based scaling support to passive governor Chanwoo Choi
     [not found]   ` <CGME20210617054647epcas1p4d2e5b1fa1ec35487701189808178da18@epcas1p4.samsung.com>
2021-06-17  6:05     ` [PATCH 1/4] PM / devfreq: passive: Fix get_target_freq when not using required-opp Chanwoo Choi
2021-06-24  1:38       ` Chanwoo Choi
     [not found]   ` <CGME20210617054647epcas1p265359058d489661e09d8d48d4937ca7b@epcas1p2.samsung.com>
2021-06-17  6:05     ` [PATCH 2/4] PM / devfreq: Export devfreq_get_freq_ragne symbol within devfreq Chanwoo Choi
2021-06-22 18:23       ` Matthias Kaehlcke
2021-07-13 19:36         ` Chanwoo Choi
     [not found]   ` <CGME20210617054647epcas1p431edaffea5bf7f3792b55dc3d91289ae@epcas1p4.samsung.com>
2021-06-17  6:05     ` [PATCH 3/4] PM / devfreq: Add cpu based scaling support to passive governor Chanwoo Choi
2021-06-17  5:51       ` Hsin-Yi Wang
2021-06-17  6:13         ` Chanwoo Choi
2021-06-22 17:42       ` Matthias Kaehlcke [this message]
2021-06-22 18:36       ` Matthias Kaehlcke
2021-06-23 20:50       ` kernel test robot
     [not found]   ` <CGME20210617054647epcas1p41cd87f03bc6f5b44b6f2d7a3e5924860@epcas1p4.samsung.com>
2021-06-17  6:05     ` [PATCH 4/4] PM / devfreq: passive: Reduce duplicate code when passive_devfreq case Chanwoo Choi
2021-06-22 18:35       ` Matthias Kaehlcke
2021-07-13 19:31         ` Chanwoo Choi

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=YNIhCxw0bnweb9SB@google.com \
    --to=mka@chromium.org \
    --cc=andrew-sh.cheng@mediatek.com \
    --cc=chanwoo@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=cwchoi00@gmail.com \
    --cc=hsinyi@chromium.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=saravanak@google.com \
    --cc=sibis@codeaurora.org \
    --cc=skannan@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.