linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ionela Voinescu <ionela.voinescu@arm.com>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Ricardo Neri <ricardo.neri@intel.com>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	Ben Segall <bsegall@google.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Len Brown <len.brown@intel.com>, Mel Gorman <mgorman@suse.de>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Valentin Schneider <vschneid@redhat.com>,
	x86@kernel.org,
	"Joel Fernandes (Google)" <joel@joelfernandes.org>,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	"Tim C . Chen" <tim.c.chen@intel.com>
Subject: Re: [PATCH v2 02/22] sched: Add interfaces for IPC classes
Date: Thu, 8 Dec 2022 08:48:46 +0000	[thread overview]
Message-ID: <Y5Gf9wGB5nFa4EDv@arm.com> (raw)
In-Reply-To: <20221128132100.30253-3-ricardo.neri-calderon@linux.intel.com>

Hi,

On Monday 28 Nov 2022 at 05:20:40 (-0800), Ricardo Neri wrote:
[..]
> +#ifndef arch_has_ipc_classes
> +/**
> + * arch_has_ipc_classes() - Check whether hardware supports IPC classes of tasks
> + *
> + * Returns: true of IPC classes of tasks are supported.
> + */
> +static __always_inline
> +bool arch_has_ipc_classes(void)
> +{
> +	return false;
> +}
> +#endif
> +
> +#ifndef arch_update_ipcc
> +/**
> + * arch_update_ipcc() - Update the IPC class of the current task
> + * @curr:		The current task
> + *
> + * Request that the IPC classification of @curr is updated.
> + *
> + * Returns: none
> + */
> +static __always_inline
> +void arch_update_ipcc(struct task_struct *curr)
> +{
> +}
> +#endif
> +
> +#ifndef arch_get_ipcc_score
> +/**
> + * arch_get_ipcc_score() - Get the IPC score of a class of task
> + * @ipcc:	The IPC class
> + * @cpu:	A CPU number
> + *
> + * Returns the performance score of an IPC class when running on @cpu.
> + * Error when either @class or @cpu are invalid.
> + */
> +static __always_inline
> +int arch_get_ipcc_score(unsigned short ipcc, int cpu)
> +{
> +	return 1;
> +}
> +#endif

The interface looks mostly alright but this arch_get_ipcc_score() leaves
unclear what are the characteristics of the returned value.

Does it have a meaning as an absolute value or is it a value on an
abstract scale? If it should be interpreted as instructions per cycle,
if I wanted to have a proper comparison between the ability of two CPUs
to handle this class of tasks then I would need to take into consideration
the maximum frequency of each CPU. If it's a performance value on an
abstract scale (more likely), similar cu capacity, then it might be good
to better define this abstract scale. That would help with the default
implementation where possibly the best choice for a return value would
be the maximum value on the scale, suggesting equal/maximum performance
for different CPUs handling the class of tasks.

I suppose you avoided returning 0 for the default implementation as you
intend that to mean the inability of the CPU to handle that class of
tasks? It would be good to document this.

> +#else /* CONFIG_IPC_CLASSES */
> +
> +#define arch_get_ipcc_score(ipcc, cpu) (-EINVAL)
> +#define arch_update_ipcc(curr)
> +
> +static inline bool sched_ipcc_enabled(void) { return false; }
> +
> +#endif /* CONFIG_IPC_CLASSES */
> +
>  #ifndef arch_scale_freq_capacity
>  /**
>   * arch_scale_freq_capacity - get the frequency scale factor of a given CPU.
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index 8154ef590b9f..eb1654b64df7 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -669,6 +669,9 @@ DEFINE_PER_CPU(struct sched_domain __rcu *, sd_numa);
>  DEFINE_PER_CPU(struct sched_domain __rcu *, sd_asym_packing);
>  DEFINE_PER_CPU(struct sched_domain __rcu *, sd_asym_cpucapacity);
>  DEFINE_STATIC_KEY_FALSE(sched_asym_cpucapacity);
> +#ifdef CONFIG_IPC_CLASSES
> +DEFINE_STATIC_KEY_FALSE(sched_ipcc);
> +#endif
>  
>  static void update_top_cache_domain(int cpu)
>  {
> @@ -2388,6 +2391,11 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
>  	if (has_asym)
>  		static_branch_inc_cpuslocked(&sched_asym_cpucapacity);
>  
> +#ifdef CONFIG_IPC_CLASSES
> +	if (arch_has_ipc_classes())
> +		static_branch_enable_cpuslocked(&sched_ipcc);
> +#endif

Wouldn't this be better placed directly in sched_init_smp()?
It's not gated by and it does not need any sched domains information.

Hope it helps,
Ionela.

> +
>  	if (rq && sched_debug_verbose) {
>  		pr_info("root domain span: %*pbl (max cpu_capacity = %lu)\n",
>  			cpumask_pr_args(cpu_map), rq->rd->max_cpu_capacity);
> -- 
> 2.25.1
> 
> 

  reply	other threads:[~2022-12-08  8:49 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 13:20 [PATCH v2 00/22] sched: Introduce IPC classes for load balance Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 01/22] sched/task_struct: Introduce IPC classes of tasks Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 02/22] sched: Add interfaces for IPC classes Ricardo Neri
2022-12-08  8:48   ` Ionela Voinescu [this message]
2022-12-14  0:31     ` Ricardo Neri
2022-12-14 23:15       ` Ionela Voinescu
2022-12-20  0:12         ` Ricardo Neri
2022-12-14  7:36   ` Lukasz Luba
2022-12-16 21:56     ` Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 03/22] sched/core: Initialize the IPC class of a new task Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 04/22] sched/core: Add user_tick as argument to scheduler_tick() Ricardo Neri
2022-12-07 12:21   ` Dietmar Eggemann
2022-12-12 18:47     ` Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 05/22] sched/core: Update the IPC class of the current task Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 06/22] sched/fair: Collect load-balancing stats for IPC classes Ricardo Neri
2022-12-07 17:00   ` Dietmar Eggemann
2022-12-12 21:41     ` Ricardo Neri
2022-12-08  8:50   ` Ionela Voinescu
2022-12-14  0:31     ` Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 07/22] sched/fair: Compute IPC class scores for load balancing Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 08/22] sched/fair: Use IPC class to pick the busiest group Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 09/22] sched/fair: Use IPC class score to select a busiest runqueue Ricardo Neri
2022-12-08  8:51   ` Ionela Voinescu
2022-12-14  0:32     ` Ricardo Neri
2022-12-14 23:16       ` Ionela Voinescu
2022-12-16 23:24         ` Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 10/22] thermal: intel: hfi: Introduce Intel Thread Director classes Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 11/22] thermal: intel: hfi: Store per-CPU IPCC scores Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 12/22] x86/cpufeatures: Add the Intel Thread Director feature definitions Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 13/22] thermal: intel: hfi: Update the IPC class of the current task Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 14/22] thermal: intel: hfi: Report the IPC class score of a CPU Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 15/22] thermal: intel: hfi: Define a default class for unclassified tasks Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 16/22] thermal: intel: hfi: Enable the Intel Thread Director Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 17/22] sched/task_struct: Add helpers for IPC classification Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 18/22] sched/core: Initialize helpers of task classification Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 19/22] thermal: intel: hfi: Implement model-specific checks for " Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 20/22] x86/cpufeatures: Add feature bit for HRESET Ricardo Neri
2022-11-28 13:20 ` [PATCH v2 21/22] x86/hreset: Configure history reset Ricardo Neri
2022-11-28 13:21 ` [PATCH v2 22/22] x86/process: Reset hardware history in context switch Ricardo Neri

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=Y5Gf9wGB5nFa4EDv@arm.com \
    --to=ionela.voinescu@arm.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joel@joelfernandes.org \
    --cc=juri.lelli@redhat.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=ricardo.neri-calderon@linux.intel.com \
    --cc=ricardo.neri@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=tim.c.chen@intel.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).