From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
Suresh B Siddha <suresh.b.siddha@intel.com>,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@elte.hu>, Dipankar Sarma <dipankar@in.ibm.com>,
Vatsa <vatsa@linux.vnet.ibm.com>,
Gautham R Shenoy <ego@in.ibm.com>,
Andi Kleen <andi@firstfloor.org>,
David Collier-Brown <davecb@sun.com>,
Tim Connors <tconnors@astro.swin.edu.au>,
Max Krasnyansky <maxk@qualcomm.com>,
Gregory Haskins <gregory.haskins@gmail.com>
Subject: Re: [RFC PATCH v5 2/7] sched: favour lower logical cpu number for sched_mc balance
Date: Mon, 15 Dec 2008 11:42:09 +0530 [thread overview]
Message-ID: <20081215061209.GB18403@balbir.in.ibm.com> (raw)
In-Reply-To: <20081211174247.2020.63646.stgit@drishya.in.ibm.com>
* Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> [2008-12-11 23:12:48]:
> Just in case two groups have identical load, prefer to move load to lower
> logical cpu number rather than the present logic of moving to higher logical
> number.
>
> find_busiest_group() tries to look for a group_leader that has spare capacity
> to take more tasks and freeup an appropriate least loaded group. Just in case
> there is a tie and the load is equal, then the group with higher logical number
> is favoured. This conflicts with user space irqbalance daemon that will move
> interrupts to lower logical number if the system utilisation is very low.
>
This patch will work well with irqbalance only when irqbalance decides
to switch to power mode and if the interrupt rate is high and
irqbalance is in performance mode and sched_mc > 1, what is the impact
of this patch?
> Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
> ---
>
> kernel/sched.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched.c b/kernel/sched.c
> index 322cd2a..6bea99b 100644
> --- a/kernel/sched.c
> +++ b/kernel/sched.c
> @@ -3264,7 +3264,7 @@ find_busiest_group(struct sched_domain *sd, int this_cpu,
> */
> if ((sum_nr_running < min_nr_running) ||
> (sum_nr_running == min_nr_running &&
> - first_cpu(group->cpumask) <
> + first_cpu(group->cpumask) >
> first_cpu(group_min->cpumask))) {
The first_cpu logic worries me a bit. This has existed for a while
already, but with the topology I see on my system, I find the cpu
numbers interleaved on my system (0,2,4 and 6) belong to one core and
odd numbers to the other.
So for a topology like (assume dual core, dual socket)
0-3
/ \
0-1 2-3
/ \ / \
0 1 2 3
If group_min is the domain with (2-3) and we are looking at
group(0-1). first_cpu of (0-1) is 0 and (2-3) is 2, how does changing
"<" to ">" help push the tasks to the lower ordered group? In the case
described above group_min continues to be (2-3).
Shouldn't the check be if (first_cpu(group->cpumask) <=
first_cpu(group_min->cpumask)?
> group_min = group;
> min_nr_running = sum_nr_running;
> @@ -3280,7 +3280,7 @@ find_busiest_group(struct sched_domain *sd, int this_cpu,
> if (sum_nr_running <= group_capacity - 1) {
> if (sum_nr_running > leader_nr_running ||
> (sum_nr_running == leader_nr_running &&
> - first_cpu(group->cpumask) >
> + first_cpu(group->cpumask) <
> first_cpu(group_leader->cpumask))) {
> group_leader = group;
> leader_nr_running = sum_nr_running;
>
>
All these changes are good, I would like to see additional statistics
that show how many decisions were taken due to new power aware
balancing logic, so that I spot the bad and corner cases based on the
statistics I see.
--
Balbir
next prev parent reply other threads:[~2008-12-15 6:12 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-11 17:42 [RFC PATCH v5 0/7] Tunable sched_mc_power_savings=n Vaidyanathan Srinivasan
1970-01-01 0:13 ` Pavel Machek
2008-12-14 20:08 ` Vaidyanathan Srinivasan
2008-12-15 8:18 ` Peter Zijlstra
2008-12-11 17:42 ` [RFC PATCH v5 1/7] sched: Framework for sched_mc/smt_power_savings=N Vaidyanathan Srinivasan
2008-12-11 18:55 ` Balbir Singh
2008-12-11 19:07 ` Vaidyanathan Srinivasan
2008-12-11 17:42 ` [RFC PATCH v5 2/7] sched: favour lower logical cpu number for sched_mc balance Vaidyanathan Srinivasan
2008-12-15 6:12 ` Balbir Singh [this message]
2008-12-15 12:05 ` Vaidyanathan Srinivasan
2008-12-11 17:42 ` [RFC PATCH v5 3/7] sched: nominate preferred wakeup cpu Vaidyanathan Srinivasan
2008-12-15 6:40 ` Balbir Singh
2008-12-15 12:14 ` Vaidyanathan Srinivasan
2008-12-11 17:43 ` [RFC PATCH v5 4/7] sched: bias task wakeups to preferred semi-idle packages Vaidyanathan Srinivasan
2008-12-15 7:01 ` Balbir Singh
2008-12-15 8:25 ` Peter Zijlstra
2008-12-15 8:33 ` Peter Zijlstra
2008-12-15 8:46 ` Balbir Singh
2008-12-15 12:25 ` Vaidyanathan Srinivasan
2008-12-15 18:02 ` Balbir Singh
2008-12-16 7:25 ` Vaidyanathan Srinivasan
2008-12-15 8:43 ` Balbir Singh
2008-12-11 17:43 ` [RFC PATCH v5 5/7] sched: activate active load balancing in new idle cpus Vaidyanathan Srinivasan
2008-12-11 17:43 ` [RFC PATCH v5 6/7] sched: add SD_BALANCE_NEWIDLE at MC and CPU level for sched_mc>0 Vaidyanathan Srinivasan
2008-12-11 17:43 ` [RFC PATCH v5 7/7] sched: idle_balance() does not call load_balance_newidle() Vaidyanathan Srinivasan
2008-12-15 7:02 ` Balbir Singh
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=20081215061209.GB18403@balbir.in.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=andi@firstfloor.org \
--cc=davecb@sun.com \
--cc=dipankar@in.ibm.com \
--cc=ego@in.ibm.com \
--cc=gregory.haskins@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
--cc=svaidy@linux.vnet.ibm.com \
--cc=tconnors@astro.swin.edu.au \
--cc=vatsa@linux.vnet.ibm.com \
--cc=venkatesh.pallipadi@intel.com \
/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