All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	peterz@infradead.org, dietmar.eggemann@arm.com,
	juri.lelli@redhat.com, rostedt@goodmis.org, mgorman@suse.de,
	bsegall@google.com
Subject: [PATCH v2] sched/fair: add comments for group_type and balancing at SD_NUMA level
Date: Mon, 18 Nov 2019 14:34:57 +0100	[thread overview]
Message-ID: <20191118133457.GB66833@gmail.com> (raw)
In-Reply-To: <7325dac4-bb26-9fcb-75bc-15b68d35b62d@arm.com>


* Valentin Schneider <valentin.schneider@arm.com> wrote:

> Hi Vincent,
> 
> On 12/11/2019 14:50, Vincent Guittot wrote:
> > Add comments to describe each state of goup_type and to add some details
> > about the load balance at NUMA level.
> > 
> > Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> 
> Suggestions/nits below. There's a bit of duplication with existing
> comments (e.g. the nice blob atop sg_imbalanced()), but I think it can't
> hurt to have the few extra lines you're introducing.
> 
> ---
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index bfdcaf91b325..ec93ebd02352 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6955,28 +6955,26 @@ enum fbq_type { regular, remote, all };
>   * group. see update_sd_pick_busiest().
>   */
>  enum group_type {
> -	/*
> -	 * The group has spare capacity that can be used to process more work.
> -	 */
> +	/* The group isn't significantly pressured and can be used to process more work */
>  	group_has_spare = 0,
>  	/*
>  	 * The group is fully used and the tasks don't compete for more CPU
> -	 * cycles. Nevetheless, some tasks might wait before running.
> +	 * cycles. Nevertheless, some tasks might wait before running.
>  	 */
>  	group_fully_busy,
>  	/*
> -	 * One task doesn't fit with CPU's capacity and must be migrated on a
> -	 * more powerful CPU.
> +	 * (SD_ASYM_CPUCAPACITY only) One task doesn't fit on its CPU's
> +	 * capacity and must be migrated to a CPU of higher capacity.
>  	 */
>  	group_misfit_task,
>  	/*
> -	 * One local CPU with higher capacity is available and task should be
> -	 * migrated on it instead on current CPU.
> +	 * (SD_ASYM_PACKING only) One local CPU with higher capacity is
> +	 * available and task should be migrated to it.
>  	 */
>  	group_asym_packing,
>  	/*
> -	 * The tasks affinity prevents the scheduler to balance the load across
> -	 * the system.
> +	 * The tasks affinity previously prevented the scheduler from balancing
> +	 * load across the system.
>  	 */
>  	group_imbalanced,

Thanks - I did a few more fixes and updates to the comments, this is how 
it ended up looking like (full patch below):

/*
 * 'group_type' describes the group of CPUs at the moment of load balancing.
 *
 * The enum is ordered by pulling priority, with the group with lowest priority
 * first so the group_type can simply be compared when selecting the busiest
 * group. See update_sd_pick_busiest().
 */
enum group_type {
	/* The group has spare capacity that can be used to run more tasks.  */
	group_has_spare = 0,
	/*
	 * The group is fully used and the tasks don't compete for more CPU
	 * cycles. Nevertheless, some tasks might wait before running.
	 */
	group_fully_busy,
	/*
	 * SD_ASYM_CPUCAPACITY only: One task doesn't fit with CPU's capacity
	 * and must be migrated to a more powerful CPU.
	 */
	group_misfit_task,
	/*
	 * SD_ASYM_PACKING only: One local CPU with higher capacity is available,
	 * and the task should be migrated to it instead of running on the
	 * current CPU.
	 */
	group_asym_packing,
	/*
	 * The tasks' affinity constraints previously prevented the scheduler
	 * from balancing the load across the system.
	 */
	group_imbalanced,
	/*
	 * The CPU is overloaded and can't provide expected CPU cycles to all
	 * tasks.
	 */
	group_overloaded
};

I also added your Acked-by, which I think was implicit? :)

Thanks,

	Ingo

=====>
From: Vincent Guittot <vincent.guittot@linaro.org>
Date: Tue, 12 Nov 2019 15:50:43 +0100
Subject: [PATCH] sched/fair: Add comments for group_type and balancing at SD_NUMA level

Add comments to describe each state of goup_type and to add some details
about the load balance at NUMA level.

[ Valentin Schneider: Updates to the comments. ]
[ mingo: Other updates to the comments. ]

Reported-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Acked-by: Valentin Schneider <valentin.schneider@arm.com>
Cc: Ben Segall <bsegall@google.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/1573570243-1903-1-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/sched/fair.c | 35 +++++++++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2fc08e7d9cd6..1f93d96dd06b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6980,17 +6980,40 @@ static unsigned long __read_mostly max_load_balance_interval = HZ/10;
 enum fbq_type { regular, remote, all };
 
 /*
- * group_type describes the group of CPUs at the moment of the load balance.
+ * 'group_type' describes the group of CPUs at the moment of load balancing.
+ *
  * The enum is ordered by pulling priority, with the group with lowest priority
- * first so the groupe_type can be simply compared when selecting the busiest
- * group. see update_sd_pick_busiest().
+ * first so the group_type can simply be compared when selecting the busiest
+ * group. See update_sd_pick_busiest().
  */
 enum group_type {
+	/* The group has spare capacity that can be used to run more tasks.  */
 	group_has_spare = 0,
+	/*
+	 * The group is fully used and the tasks don't compete for more CPU
+	 * cycles. Nevertheless, some tasks might wait before running.
+	 */
 	group_fully_busy,
+	/*
+	 * SD_ASYM_CPUCAPACITY only: One task doesn't fit with CPU's capacity
+	 * and must be migrated to a more powerful CPU.
+	 */
 	group_misfit_task,
+	/*
+	 * SD_ASYM_PACKING only: One local CPU with higher capacity is available,
+	 * and the task should be migrated to it instead of running on the
+	 * current CPU.
+	 */
 	group_asym_packing,
+	/*
+	 * The tasks' affinity constraints previously prevented the scheduler
+	 * from balancing the load across the system.
+	 */
 	group_imbalanced,
+	/*
+	 * The CPU is overloaded and can't provide expected CPU cycles to all
+	 * tasks.
+	 */
 	group_overloaded
 };
 
@@ -8589,7 +8612,11 @@ static inline void calculate_imbalance(struct lb_env *env, struct sd_lb_stats *s
 
 	/*
 	 * Try to use spare capacity of local group without overloading it or
-	 * emptying busiest
+	 * emptying busiest.
+	 * XXX Spreading tasks across NUMA nodes is not always the best policy
+	 * and special care should be taken for SD_NUMA domain level before
+	 * spreading the tasks. For now, load_balance() fully relies on
+	 * NUMA_BALANCING and fbq_classify_group/rq to override the decision.
 	 */
 	if (local->group_type == group_has_spare) {
 		if (busiest->group_type > group_fully_busy) {


  reply	other threads:[~2019-11-18 13:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12 14:50 [PATCH] sched/fair: add comments for group_type and balancing at SD_NUMA level Vincent Guittot
2019-11-12 17:42 ` Valentin Schneider
2019-11-18 13:34   ` Ingo Molnar [this message]
2019-11-18 14:06     ` [PATCH v2] " Valentin Schneider
2019-11-18 17:42 ` [tip: sched/core] sched/fair: Add " tip-bot2 for Vincent Guittot

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=20191118133457.GB66833@gmail.com \
    --to=mingo@kernel.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.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.