| Message ID | 1401431772-14320-14-git-send-email-yuyang.du@intel.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Fri, May 30, 2014 at 02:36:09PM +0800, Yuyang Du wrote: > We intercept load balancing to contain the load and load balancing in > the consolidated CPUs according to our consolidating mechanism. > > In wakeup/fork/exec load balaning, when to find the idlest sched_group, > we first try to find the consolidated group Anything with intercept in is a complete non-starter. You still fully duplicate the logic. You really didn't get anything I said, did you? Please as to go back to square 1 and read again. So take a step back and try and explain what and why you're doing things, also try and look at what other people are doing. If I see another patch from you within two weeks I'll simply delete it, there's no way you can read up and fix everything in such a short time.
On Tue, Jun 03, 2014 at 02:27:02PM +0200, Peter Zijlstra wrote: > On Fri, May 30, 2014 at 02:36:09PM +0800, Yuyang Du wrote: > > We intercept load balancing to contain the load and load balancing in > > the consolidated CPUs according to our consolidating mechanism. > > > > In wakeup/fork/exec load balaning, when to find the idlest sched_group, > > we first try to find the consolidated group > > Anything with intercept in is a complete non-starter. You still fully > duplicate the logic. > > You really didn't get anything I said, did you? > > Please as to go back to square 1 and read again. > > So take a step back and try and explain what and why you're doing > things, also try and look at what other people are doing. If I see > another patch from you within two weeks I'll simply delete it, there's > no way you can read up and fix everything in such a short time. Hi Peter, Thanks for your reply, it hurts though, :( I was concerned about what you said back, which should be this one: PeterZ: Fourthly, I'm _never_ going to merge anything that hijacks the load balancer and does some random other thing. There's going to be a single load-balancer full stop. But some explanation to this interception/hijack. It is driven by a sched policy (SD_WORKLOAD_CONSOLIDATION) and the resulting effect of that policy if enabled, or still part of the load balancer. Can't do/call it that way? Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d40ec9e..1c9ac08 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4475,7 +4475,7 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f } while (sd) { - struct sched_group *group; + struct sched_group *group = NULL; int weight; if (!(sd->flags & sd_flag)) { @@ -4483,7 +4483,12 @@ select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_f continue; } - group = find_idlest_group(sd, p, cpu, sd_flag); + if (sd->flags & SD_WORKLOAD_CONSOLIDATION) + group = wc_find_group(sd, p, cpu); + + if (!group) + group = find_idlest_group(sd, p, cpu, sd_flag); + if (!group) { sd = sd->child; continue;
We intercept load balancing to contain the load and load balancing in the consolidated CPUs according to our consolidating mechanism. In wakeup/fork/exec load balaning, when to find the idlest sched_group, we first try to find the consolidated group Signed-off-by: Yuyang Du <yuyang.du@intel.com> --- kernel/sched/fair.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)