From: Preeti U Murthy <preeti@linux.vnet.ibm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>, peterz@infradead.org
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, pjt@google.com,
Morten.Rasmussen@arm.com, cmetcalf@tilera.com,
tony.luck@intel.com, alex.shi@linaro.org,
linaro-kernel@lists.linaro.org, rjw@sisk.pl,
paulmck@linux.vnet.ibm.com, corbet@lwn.net, tglx@linutronix.de,
len.brown@intel.com, arjan@linux.intel.com,
amit.kucheria@linaro.org, james.hogan@imgtec.com,
schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
Dietmar.Eggemann@arm.com
Subject: Re: [RFC] sched: CPU topology try
Date: Tue, 07 Jan 2014 15:10:21 +0530 [thread overview]
Message-ID: <52CBCB85.8050607@linux.vnet.ibm.com> (raw)
In-Reply-To: <1387372431-2644-1-git-send-email-vincent.guittot@linaro.org>
Hi Vincent, Peter,
On 12/18/2013 06:43 PM, Vincent Guittot wrote:
> This patch applies on top of the two patches [1][2] that have been proposed by
> Peter for creating a new way to initialize sched_domain. It includes some minor
> compilation fixes and a trial of using this new method on ARM platform.
> [1] https://lkml.org/lkml/2013/11/5/239
> [2] https://lkml.org/lkml/2013/11/5/449
>
> Based on the results of this tests, my feeling about this new way to init the
> sched_domain is a bit mitigated.
>
> The good point is that I have been able to create the same sched_domain
> topologies than before and even more complex ones (where a subset of the cores
> in a cluster share their powergating capabilities). I have described various
> topology results below.
>
> I use a system that is made of a dual cluster of quad cores with hyperthreading
> for my examples.
>
> If one cluster (0-7) can powergate its cores independantly but not the other
> cluster (8-15) we have the following topology, which is equal to what I had
> previously:
>
> CPU0:
> domain 0: span 0-1 level: SMT
> flags: SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES | SD_SHARE_POWERDOMAIN
> groups: 0 1
> domain 1: span 0-7 level: MC
> flags: SD_SHARE_PKG_RESOURCES
> groups: 0-1 2-3 4-5 6-7
> domain 2: span 0-15 level: CPU
> flags:
> groups: 0-7 8-15
>
> CPU8
> domain 0: span 8-9 level: SMT
> flags: SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES | SD_SHARE_POWERDOMAIN
> groups: 8 9
> domain 1: span 8-15 level: MC
> flags: SD_SHARE_PKG_RESOURCES | SD_SHARE_POWERDOMAIN
> groups: 8-9 10-11 12-13 14-15
> domain 2: span 0-15 level CPU
> flags:
> groups: 8-15 0-7
>
> We can even describe some more complex topologies if a susbset (2-7) of the
> cluster can't powergate independatly:
>
> CPU0:
> domain 0: span 0-1 level: SMT
> flags: SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES | SD_SHARE_POWERDOMAIN
> groups: 0 1
> domain 1: span 0-7 level: MC
> flags: SD_SHARE_PKG_RESOURCES
> groups: 0-1 2-7
> domain 2: span 0-15 level: CPU
> flags:
> groups: 0-7 8-15
>
> CPU2:
> domain 0: span 2-3 level: SMT
> flags: SD_SHARE_CPUPOWER | SD_SHARE_PKG_RESOURCES | SD_SHARE_POWERDOMAIN
> groups: 0 1
> domain 1: span 2-7 level: MC
> flags: SD_SHARE_PKG_RESOURCES | SD_SHARE_POWERDOMAIN
> groups: 2-7 4-5 6-7
> domain 2: span 0-7 level: MC
> flags: SD_SHARE_PKG_RESOURCES
> groups: 2-7 0-1
> domain 3: span 0-15 level: CPU
> flags:
> groups: 0-7 8-15
>
> In this case, we have an aditionnal sched_domain MC level for this subset (2-7)
> of cores so we can trigger some load balance in this subset before doing that
> on the complete cluster (which is the last level of cache in my example)
>
> We can add more levels that will describe other dependency/independency like
> the frequency scaling dependency and as a result the final sched_domain
> topology will have additional levels (if they have not been removed during
> the degenerate sequence)
>
> My concern is about the configuration of the table that is used to create the
> sched_domain. Some levels are "duplicated" with different flags configuration
> which make the table not easily readable and we must also take care of the
> order because parents have to gather all cpus of its childs. So we must
> choose which capabilities will be a subset of the other one. The order is
> almost straight forward when we describe 1 or 2 kind of capabilities
> (package ressource sharing and power sharing) but it can become complex if we
> want to add more.
What if we want to add arch specific flags to the NUMA domain? Currently
with Peter's patch:https://lkml.org/lkml/2013/11/5/239 and this patch,
the arch can modify the sd flags of the topology levels till just before
the NUMA domain. In sd_init_numa(), the flags for the NUMA domain get
initialized. We need to perhaps call into arch here to probe for
additional flags?
Thanks
Regards
Preeti U Murthy
>
> Regards
> Vincent
>
next prev parent reply other threads:[~2014-01-07 9:43 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-18 11:52 [RFC][PATCH v5 00/14] sched: packing tasks Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 01/14] sched: add a new arch_sd_local_flags for sched_domain init Vincent Guittot
2013-11-05 14:06 ` Peter Zijlstra
2013-11-05 14:57 ` Vincent Guittot
2013-11-05 22:27 ` Peter Zijlstra
2013-11-06 10:10 ` Vincent Guittot
2013-11-06 13:53 ` Martin Schwidefsky
2013-11-06 14:08 ` Peter Zijlstra
2013-11-12 17:43 ` Dietmar Eggemann
2013-11-12 18:08 ` Peter Zijlstra
2013-11-13 15:47 ` Dietmar Eggemann
2013-11-13 16:29 ` Peter Zijlstra
2013-11-14 10:49 ` Morten Rasmussen
2013-11-14 12:07 ` Peter Zijlstra
2013-12-18 13:13 ` [RFC] sched: CPU topology try Vincent Guittot
2013-12-23 17:22 ` Dietmar Eggemann
2014-01-06 13:41 ` Vincent Guittot
2014-01-06 16:31 ` Peter Zijlstra
2014-01-07 8:32 ` Vincent Guittot
2014-01-07 13:22 ` Peter Zijlstra
2014-01-07 14:10 ` Peter Zijlstra
2014-01-07 15:41 ` Morten Rasmussen
2014-01-07 20:49 ` Peter Zijlstra
2014-01-08 8:32 ` Alex Shi
2014-01-08 8:37 ` Peter Zijlstra
2014-01-08 12:52 ` Morten Rasmussen
2014-01-08 13:04 ` Peter Zijlstra
2014-01-08 13:33 ` Morten Rasmussen
2014-01-08 12:35 ` Morten Rasmussen
2014-01-08 12:42 ` Peter Zijlstra
2014-01-08 12:45 ` Peter Zijlstra
2014-01-08 13:27 ` Morten Rasmussen
2014-01-08 13:32 ` Peter Zijlstra
2014-01-08 13:45 ` Morten Rasmussen
2014-01-07 14:11 ` Vincent Guittot
2014-01-07 15:37 ` Morten Rasmussen
2014-01-08 8:37 ` Alex Shi
2014-01-06 16:28 ` Peter Zijlstra
2014-01-06 17:15 ` Morten Rasmussen
2014-01-07 9:57 ` Peter Zijlstra
2014-01-01 5:00 ` Preeti U Murthy
2014-01-06 16:33 ` Peter Zijlstra
2014-01-06 16:37 ` Arjan van de Ven
2014-01-06 16:48 ` Peter Zijlstra
2014-01-06 16:54 ` Peter Zijlstra
2014-01-06 17:13 ` Arjan van de Ven
2014-01-07 12:40 ` Vincent Guittot
2014-01-06 16:21 ` Peter Zijlstra
2014-01-07 8:22 ` Vincent Guittot
2014-01-07 9:40 ` Preeti U Murthy [this message]
2014-01-07 9:50 ` Peter Zijlstra
2014-01-07 10:39 ` Preeti U Murthy
2014-01-07 11:13 ` Peter Zijlstra
2014-01-07 16:31 ` Preeti U Murthy
2014-01-07 11:20 ` Morten Rasmussen
2014-01-07 12:31 ` Vincent Guittot
2014-01-07 16:51 ` Preeti U Murthy
2013-10-18 11:52 ` [RFC][PATCH v5 03/14] sched: define pack buddy CPUs Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 04/14] sched: do load balance only with packing cpus Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 05/14] sched: add a packing level knob Vincent Guittot
2013-11-12 10:32 ` Peter Zijlstra
2013-11-12 10:44 ` Vincent Guittot
2013-11-12 10:55 ` Peter Zijlstra
2013-11-12 10:57 ` Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 06/14] sched: create a new field with available capacity Vincent Guittot
2013-11-12 10:34 ` Peter Zijlstra
2013-11-12 11:05 ` Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 07/14] sched: get CPU's activity statistic Vincent Guittot
2013-11-12 10:36 ` Peter Zijlstra
2013-11-12 10:41 ` Peter Zijlstra
2013-10-18 11:52 ` [RFC][PATCH v5 08/14] sched: move load idx selection in find_idlest_group Vincent Guittot
2013-11-12 10:49 ` Peter Zijlstra
2013-11-27 14:10 ` [tip:sched/core] sched/fair: Move " tip-bot for Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 09/14] sched: update the packing cpu list Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 10/14] sched: init this_load to max in find_idlest_group Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 11/14] sched: add a SCHED_PACKING_TASKS config Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 12/14] sched: create a statistic structure Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 13/14] sched: differantiate idle cpu Vincent Guittot
2013-10-18 11:52 ` [RFC][PATCH v5 14/14] cpuidle: set the current wake up latency Vincent Guittot
2013-11-11 11:33 ` [RFC][PATCH v5 00/14] sched: packing tasks Catalin Marinas
2013-11-11 16:36 ` Peter Zijlstra
2013-11-11 16:39 ` Arjan van de Ven
2013-11-11 18:18 ` Catalin Marinas
2013-11-11 18:20 ` Arjan van de Ven
2013-11-12 12:06 ` Morten Rasmussen
2013-11-12 16:48 ` Arjan van de Ven
2013-11-12 23:14 ` Catalin Marinas
2013-11-13 16:13 ` Arjan van de Ven
2013-11-13 16:45 ` Catalin Marinas
2013-11-13 17:56 ` Arjan van de Ven
2013-11-12 17:40 ` Catalin Marinas
2013-11-25 18:55 ` Daniel Lezcano
2013-11-11 16:38 ` Peter Zijlstra
2013-11-11 16:40 ` Arjan van de Ven
2013-11-12 10:36 ` Vincent Guittot
2013-11-11 16:54 ` Morten Rasmussen
2013-11-11 18:31 ` Catalin Marinas
2013-11-11 19:26 ` Arjan van de Ven
2013-11-11 22:43 ` Nicolas Pitre
2013-11-11 23:43 ` Catalin Marinas
2013-11-12 12:35 ` 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=52CBCB85.8050607@linux.vnet.ibm.com \
--to=preeti@linux.vnet.ibm.com \
--cc=Dietmar.Eggemann@arm.com \
--cc=Morten.Rasmussen@arm.com \
--cc=alex.shi@linaro.org \
--cc=amit.kucheria@linaro.org \
--cc=arjan@linux.intel.com \
--cc=cmetcalf@tilera.com \
--cc=corbet@lwn.net \
--cc=heiko.carstens@de.ibm.com \
--cc=james.hogan@imgtec.com \
--cc=len.brown@intel.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=rjw@sisk.pl \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vincent.guittot@linaro.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 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).