On Monday 29 October 2012 06:57 PM, Vincent Guittot wrote:
On 24 October 2012 17:21, Santosh Shilimkar <santosh.shilim...@ti.com> wrote:
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:

Look for an idle CPU close the pack buddy CPU whenever possible.

s/close/close to

yes


The goal is to prevent the wake up of a CPU which doesn't share the power
line of the pack CPU

Signed-off-by: Vincent Guittot <vincent.guit...@linaro.org>
---
   kernel/sched/fair.c |   18 ++++++++++++++++++
   1 file changed, 18 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6df53b5..f76acdc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5158,7 +5158,25 @@ static struct {

   static inline int find_new_ilb(int call_cpu)
   {
+       struct sched_domain *sd;
         int ilb = cpumask_first(nohz.idle_cpus_mask);
+       int buddy = per_cpu(sd_pack_buddy, call_cpu);
+
+       /*
+        * If we have a pack buddy CPU, we try to run load balance on a
CPU
+        * that is close to the buddy.
+        */
+       if (buddy != -1)
+               for_each_domain(buddy, sd) {
+                       if (sd->flags & SD_SHARE_CPUPOWER)
+                               continue;

Do you mean SD_SHARE_POWERLINE here ?

No, I just don't want to take hyperthread level for ILB


+
+                       ilb = cpumask_first_and(sched_domain_span(sd),
+                                       nohz.idle_cpus_mask);
+
+                       if (ilb < nr_cpu_ids)
+                               break;
+               }

         if (ilb < nr_cpu_ids && idle_cpu(ilb))
                 return ilb;

Can you please expand "idle CPU _close_ the pack buddy CPU" ?

The goal is to packed  the tasks on the pack buddy CPU so when the
scheduler needs to start ILB, I try to wake up a CPU that is close to
the buddy and preferably in the same cluster

I see your point now. Thanks for clarification.

Regards
santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to