From: benh@kernel.crashing.org (Benjamin Herrenschmidt)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 6/6] sched: powerpc: Add SD_SHARE_POWERDOMAIN for SMT level
Date: Sun, 23 Mar 2014 14:12:06 +1100 [thread overview]
Message-ID: <1395544326.3460.98.camel@pasglop> (raw)
In-Reply-To: <532E3DB4.9060908@linux.vnet.ibm.com>
On Sun, 2014-03-23 at 07:19 +0530, Preeti U Murthy wrote:
> We were discussing the impact of this consolidation and we are not too
> sure if it will yield us good power efficiency. So we would want to
> experiment with the power aware scheduler to find the "sweet spot" for
> the number of threads to consolidate to and more importantly if there
> is
> one such number at all. Else we would not want to go this way at all.
> Hence it looks best if this patch is dropped until we validate it. We
> don't want the code getting in and then out if we find out later there
> are no benefits to it.
>
> I am sorry that I suggested this patch a bit pre-mature in the
> experimentation and validation stage. When you release the load
> balancing patchset for power aware scheduler I shall validate this
> patch. But until then its best if it does not get merged.
It's quite possible that we never find a correct "sweet spot" for all
workloads.
Ideally, the "target" number of used threads per core should be a
tunable so that the user / distro can "tune" based on a given workload
whether to pack cores and how much to pack them, vs. spreading the
workload. Akin to scheduling for performance vs. power in a way (though
lower perf usually means higher power due to longer running jobs of
course).
In any case, we need to experiment.
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
peterz@infradead.org, mingo@kernel.org,
linux-kernel@vger.kernel.org, tony.luck@intel.com,
fenghua.yu@intel.com, schwidefsky@de.ibm.com,
james.hogan@imgtec.com, cmetcalf@tilera.com,
linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org,
dietmar.eggemann@arm.com, linaro-kernel@lists.linaro.org
Subject: Re: [PATCH v3 6/6] sched: powerpc: Add SD_SHARE_POWERDOMAIN for SMT level
Date: Sun, 23 Mar 2014 14:12:06 +1100 [thread overview]
Message-ID: <1395544326.3460.98.camel@pasglop> (raw)
In-Reply-To: <532E3DB4.9060908@linux.vnet.ibm.com>
On Sun, 2014-03-23 at 07:19 +0530, Preeti U Murthy wrote:
> We were discussing the impact of this consolidation and we are not too
> sure if it will yield us good power efficiency. So we would want to
> experiment with the power aware scheduler to find the "sweet spot" for
> the number of threads to consolidate to and more importantly if there
> is
> one such number at all. Else we would not want to go this way at all.
> Hence it looks best if this patch is dropped until we validate it. We
> don't want the code getting in and then out if we find out later there
> are no benefits to it.
>
> I am sorry that I suggested this patch a bit pre-mature in the
> experimentation and validation stage. When you release the load
> balancing patchset for power aware scheduler I shall validate this
> patch. But until then its best if it does not get merged.
It's quite possible that we never find a correct "sweet spot" for all
workloads.
Ideally, the "target" number of used threads per core should be a
tunable so that the user / distro can "tune" based on a given workload
whether to pack cores and how much to pack them, vs. spreading the
workload. Akin to scheduling for performance vs. power in a way (though
lower perf usually means higher power due to longer running jobs of
course).
In any case, we need to experiment.
Cheers,
Ben.
next prev parent reply other threads:[~2014-03-23 3:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-19 16:22 [PATCH v3 0/6] rework sched_domain topology description Vincent Guittot
2014-03-19 16:22 ` Vincent Guittot
2014-03-19 16:22 ` [PATCH v3 1/6] sched: rework of sched_domain topology definition Vincent Guittot
2014-03-19 16:22 ` Vincent Guittot
2014-03-20 12:41 ` Dietmar Eggemann
2014-03-20 12:41 ` Dietmar Eggemann
2014-03-20 17:02 ` Vincent Guittot
2014-03-20 17:02 ` Vincent Guittot
2014-03-20 17:18 ` Dietmar Eggemann
2014-03-20 17:18 ` Dietmar Eggemann
2014-03-21 10:04 ` Vincent Guittot
2014-03-21 10:04 ` Vincent Guittot
2014-03-24 14:02 ` Dietmar Eggemann
2014-03-24 14:02 ` Dietmar Eggemann
2014-03-19 16:22 ` [PATCH v3 2/6] sched: s390: create a dedicated topology table Vincent Guittot
2014-03-19 16:22 ` Vincent Guittot
2014-03-19 16:22 ` [PATCH v3 3/6] sched: powerpc: " Vincent Guittot
2014-03-19 16:22 ` Vincent Guittot
2014-03-19 16:22 ` [PATCH v3 4/6] sched: add a new SD_SHARE_POWERDOMAIN for sched_domain Vincent Guittot
2014-03-19 16:22 ` Vincent Guittot
2014-03-19 16:22 ` [PATCH 5/6] sched: ARM: create a dedicated scheduler topology table Vincent Guittot
2014-03-19 16:22 ` Vincent Guittot
2014-03-19 16:22 ` [PATCH v3 6/6] sched: powerpc: Add SD_SHARE_POWERDOMAIN for SMT level Vincent Guittot
2014-03-19 16:22 ` Vincent Guittot
2014-03-23 1:49 ` Preeti U Murthy
2014-03-23 1:49 ` Preeti U Murthy
2014-03-23 3:12 ` Benjamin Herrenschmidt [this message]
2014-03-23 3:12 ` Benjamin Herrenschmidt
2014-03-24 8:21 ` Vincent Guittot
2014-03-24 8:21 ` Vincent Guittot
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=1395544326.3460.98.camel@pasglop \
--to=benh@kernel.crashing.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.