linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: preeti@linux.vnet.ibm.com (Preeti U Murthy)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 02/13] sched:Pick the apt busy sched group during load balancing
Date: Thu, 25 Oct 2012 15:55:03 +0530	[thread overview]
Message-ID: <20121025102503.21022.35291.stgit@preeti.in.ibm.com> (raw)
In-Reply-To: <20121025102045.21022.92489.stgit@preeti.in.ibm.com>

If a sched group has passed the test for sufficient load in
update_sg_lb_stats,to qualify for load balancing,then PJT's
metrics has to be used to qualify the right sched group as the busiest group.

The scenario which led to this patch is shown below:
Consider Task1 and Task2 to be a long running task
and Tasks 3,4,5,6 to be short running tasks

			Task3
			Task4
Task1			Task5
Task2			Task6
------			------
SCHED_GRP1		SCHED_GRP2

Normal load calculator would qualify SCHED_GRP2 as
the candidate for sd->busiest due to the following loads
that it calculates.

SCHED_GRP1:2048
SCHED_GRP2:4096

Load calculator would probably qualify SCHED_GRP1 as the candidate
for sd->busiest due to the following loads that it calculates

SCHED_GRP1:3200
SCHED_GRP2:1156

This patch aims to strike a balance between the loads of the
group and the number of tasks running on the group to decide the
busiest group in the sched_domain.

This means we will need to use the PJT's metrics but with an
additional constraint.

Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
 kernel/sched/fair.c |   25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e02dad4..aafa3c1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -165,7 +165,8 @@ void sched_init_granularity(void)
 #else
 # define WMULT_CONST	(1UL << 32)
 #endif
-
+#define NR_THRESHOLD 2
+#define LOAD_THRESHOLD 1
 #define WMULT_SHIFT	32
 
 /*
@@ -4169,6 +4170,7 @@ struct sd_lb_stats {
 	/* Statistics of the busiest group */
 	unsigned int  busiest_idle_cpus;
 	unsigned long max_load;
+	u64 max_sg_load; /* Equivalent of max_load but calculated using pjt's metric*/
 	unsigned long busiest_load_per_task;
 	unsigned long busiest_nr_running;
 	unsigned long busiest_group_capacity;
@@ -4628,8 +4630,24 @@ static bool update_sd_pick_busiest(struct lb_env *env,
 				   struct sched_group *sg,
 				   struct sg_lb_stats *sgs)
 {
-	if (sgs->avg_load <= sds->max_load)
-		return false;
+	/* Use PJT's metrics to qualify a sched_group as busy
+ 	 *
+ 	 * But a low load sched group may be queueing up many tasks
+ 	 * So before dismissing a sched group with lesser load,ensure
+ 	 * that the number of processes on it is checked if it is
+ 	 * not too less loaded than the max load so far
+ 	 *
+ 	 * But as of now as LOAD_THRESHOLD is 1,this check is a nop.
+ 	 * But we could vary LOAD_THRESHOLD suitably to bring in this check
+ 	 */
+	if (sgs->avg_cfs_runnable_load <= sds->max_sg_load) {
+		if (sgs->avg_cfs_runnable_load > LOAD_THRESHOLD * sds->max_sg_load) {
+			if (sgs->sum_nr_running <= (NR_THRESHOLD + sds->busiest_nr_running))
+				return false;
+		} else {
+			return false;
+		}
+	}
 
 	if (sgs->sum_nr_running > sgs->group_capacity)
 		return true;
@@ -4708,6 +4726,7 @@ static inline void update_sd_lb_stats(struct lb_env *env,
 			sds->this_idle_cpus = sgs.idle_cpus;
 		} else if (update_sd_pick_busiest(env, sds, sg, &sgs)) {
 			sds->max_load = sgs.avg_load;
+			sds->max_sg_load = sgs.avg_cfs_runnable_load;
 			sds->busiest = sg;
 			sds->busiest_nr_running = sgs.sum_nr_running;
 			sds->busiest_idle_cpus = sgs.idle_cpus;

  parent reply	other threads:[~2012-10-25 10:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-25 10:24 [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler Preeti U Murthy
2012-10-25 10:24 ` [RFC PATCH 01/13] sched:Prevent movement of short running tasks during load balancing Preeti U Murthy
2012-10-25 10:25 ` Preeti U Murthy [this message]
2012-10-25 10:25 ` [RFC PATCH 03/13] sched:Decide whether there be transfer of loads based on the PJT's metric Preeti U Murthy
2012-10-25 10:25 ` [RFC PATCH 04/13] sched:Decide group_imb using " Preeti U Murthy
2012-10-25 10:25 ` [RFC PATCH 05/13] sched:Calculate imbalance " Preeti U Murthy
2012-10-25 10:25 ` [RFC PATCH 06/13] sched: Changing find_busiest_queue to use " Preeti U Murthy
2012-10-25 10:25 ` [RFC PATCH 07/13] sched: Change move_tasks " Preeti U Murthy
2012-10-25 10:25 ` [RFC PATCH 08/13] sched: Some miscallaneous changes in load_balance Preeti U Murthy
2012-10-25 10:25 ` [RFC PATCH 09/13] sched: Modify check_asym_packing to use PJT's metric Preeti U Murthy
2012-10-25 10:26 ` [RFC PATCH 10/13] sched: Modify fix_small_imbalance " Preeti U Murthy
2012-10-25 10:26 ` [RFC PATCH 11/13] sched: Modify find_idlest_group " Preeti U Murthy
2012-10-25 10:26 ` [RFC PATCH 12/13] sched: Modify find_idlest_cpu " Preeti U Murthy
2012-10-25 10:26 ` [RFC PATCH 13/13] sched: Modifying wake_affine " Preeti U Murthy
2012-10-25 10:33 ` [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler Preeti Murthy
2012-10-25 15:56 ` Peter Zijlstra
2012-10-25 18:00   ` Preeti U Murthy
2012-10-25 18:12   ` Preeti U Murthy
2012-10-26 12:29     ` Peter Zijlstra
2012-10-26 13:07       ` Ingo Molnar
2012-10-27  3:36         ` Preeti U Murthy
2012-10-27  3:33       ` Preeti U Murthy

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=20121025102503.21022.35291.stgit@preeti.in.ibm.com \
    --to=preeti@linux.vnet.ibm.com \
    --cc=linux-arm-kernel@lists.infradead.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).