From: Peter Zijlstra <peterz@infradead.org>
To: Michael Neuling <mikey@neuling.org>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
Gautham R Shenoy <ego@in.ibm.com>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 1/5] sched: fix capacity calculations for SMT4
Date: Tue, 13 Apr 2010 14:29:26 +0200 [thread overview]
Message-ID: <1271161766.4807.1280.camel@twins> (raw)
In-Reply-To: <20100409062118.D4096CBB6C@localhost.localdomain>
On Fri, 2010-04-09 at 16:21 +1000, Michael Neuling wrote:
> When calculating capacity we use the following calculation:
>=20
> capacity =3D DIV_ROUND_CLOSEST(power, SCHED_LOAD_SCALE);
>=20
> In SMT2, power will be 1178/2 (provided we are not scaling power with
> freq say) and SCHED_LOAD_SCALE will be 1024, resulting in capacity
> being 1.
>=20
> With SMT4 however, power will be 1178/4, hence capacity will end up as
> 0.
>=20
> Fix this by ensuring capacity is always at least 1 after this
> calculation.
>=20
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> I'm not sure this is the correct fix but this works for me. =20
Right, so I suspect this will indeed break some things.
We initially allowed 0 capacity for when a cpu is consumed by an RT task
and there simply isn't much capacity left, in that case you really want
to try and move load to your sibling cpus if possible.
However you're right that this goes awry in your case.
One thing to look at is if that 15% increase is indeed representative
for the power7 cpu, it having 4 SMT threads seems to suggest there was
significant gains, otherwise they'd not have wasted the silicon.
(The broken x86 code was meant to actually compute the SMT gain, so that
we'd not have to guess the 15%)
Now, increasing this will only marginally fix the issue, since if you
end up with 512 per thread it only takes a very tiny amount of RT
workload to drop below and end up at 0 again.
One thing we could look at is using the cpu base power to compute
capacity from. We'd have to add another field to sched_group and store
power before we do the scale_rt_power() stuff.
Thoughts?
> kernel/sched_fair.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>=20
> Index: linux-2.6-ozlabs/kernel/sched_fair.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- linux-2.6-ozlabs.orig/kernel/sched_fair.c
> +++ linux-2.6-ozlabs/kernel/sched_fair.c
> @@ -1482,6 +1482,7 @@ static int select_task_rq_fair(struct ta
> }
> =20
> capacity =3D DIV_ROUND_CLOSEST(power, SCHED_LOAD_SCALE);
> + capacity =3D max(capacity, 1UL);
> =20
> if (tmp->flags & SD_POWERSAVINGS_BALANCE)
> nr_running /=3D 2;
> @@ -2488,6 +2489,7 @@ static inline void update_sg_lb_stats(st
> =20
> sgs->group_capacity =3D
> DIV_ROUND_CLOSEST(group->cpu_power, SCHED_LOAD_SCALE);
> + sgs->group_capacity =3D max(sgs->group_capacity, 1UL);
> }
> =20
> /**
> @@ -2795,9 +2797,11 @@ find_busiest_queue(struct sched_group *g
> =20
> for_each_cpu(i, sched_group_cpus(group)) {
> unsigned long power =3D power_of(i);
> - unsigned long capacity =3D DIV_ROUND_CLOSEST(power, SCHED_LOAD_SCALE);
> + unsigned long capacity;
> unsigned long wl;
> =20
> + capacity =3D max(DIV_ROUND_CLOSEST(power, SCHED_LOAD_SCALE), 1UL);
> +
> if (!cpumask_test_cpu(i, cpus))
> continue;
> =20
next prev parent reply other threads:[~2010-04-13 12:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-09 6:21 [PATCH 0/5] sched: asymmetrical packing for POWER7 SMT4 Michael Neuling
2010-04-09 6:21 ` [PATCH 1/5] sched: fix capacity calculations for SMT4 Michael Neuling
2010-04-13 12:29 ` Peter Zijlstra [this message]
2010-04-14 4:28 ` Michael Neuling
2010-04-16 13:58 ` Peter Zijlstra
2010-04-18 21:34 ` Michael Neuling
2010-04-19 14:49 ` Peter Zijlstra
2010-04-19 20:45 ` Michael Neuling
2010-04-29 6:55 ` Michael Neuling
2010-05-31 8:33 ` Peter Zijlstra
2010-06-01 22:52 ` Vaidyanathan Srinivasan
2010-06-03 8:56 ` Peter Zijlstra
2010-06-07 15:06 ` Srivatsa Vaddagiri
2010-04-09 6:21 ` [PATCH 3/5] powerpc: enabled asymmetric SMT scheduling on POWER7 Michael Neuling
2010-04-09 6:48 ` Michael Neuling
2010-04-09 6:21 ` [PATCH 4/5] sched: Mark the balance type for use in need_active_balance() Michael Neuling
2010-04-13 12:29 ` Peter Zijlstra
2010-04-15 4:15 ` Michael Neuling
2010-04-09 6:21 ` [PATCH 2/5] sched: add asymmetric packing option for sibling domain Michael Neuling
2010-04-13 12:29 ` Peter Zijlstra
2010-04-14 6:09 ` Michael Neuling
2010-04-09 6:21 ` [PATCH 5/5] sched: make fix_small_imbalance work with asymmetric packing Michael Neuling
2010-04-13 12:29 ` Peter Zijlstra
2010-04-14 1:31 ` Suresh Siddha
2010-04-15 5:06 ` Michael Neuling
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=1271161766.4807.1280.camel@twins \
--to=peterz@infradead.org \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mikey@neuling.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@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;
as well as URLs for NNTP newsgroup(s).