From: alex.shi@intel.com (Alex Shi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 3/6] sched: pack small tasks
Date: Thu, 13 Dec 2012 10:43:52 +0800 [thread overview]
Message-ID: <50C940E8.2020001@intel.com> (raw)
In-Reply-To: <50C93AC1.1060202@intel.com>
On 12/13/2012 10:17 AM, Alex Shi wrote:
> On 12/12/2012 09:31 PM, Vincent Guittot wrote:
>> During the creation of sched_domain, we define a pack buddy CPU for each CPU
>> when one is available. We want to pack at all levels where a group of CPU can
>> be power gated independently from others.
>> On a system that can't power gate a group of CPUs independently, the flag is
>> set at all sched_domain level and the buddy is set to -1. This is the default
>> behavior.
>> On a dual clusters / dual cores system which can power gate each core and
>> cluster independently, the buddy configuration will be :
>>
>> | Cluster 0 | Cluster 1 |
>> | CPU0 | CPU1 | CPU2 | CPU3 |
>> -----------------------------------
>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>>
>> Small tasks tend to slip out of the periodic load balance so the best place
>> to choose to migrate them is during their wake up. The decision is in O(1) as
>> we only check again one buddy CPU
>
> Just have a little worry about the scalability on a big machine, like on
> a 4 sockets NUMA machine * 8 cores * HT machine, the buddy cpu in whole
> system need care 64 LCPUs. and in your case cpu0 just care 4 LCPU. That
> is different on task distribution decision.
In above big machine example, only one buddy cpu is not sufficient on
each of level, like for 4 sockets level, maybe tasks can just full fill
2 sockets, then we just use 2 sockets, that is more performance/power
efficient. But one buddy cpu here need to spread tasks to 4 sockets all.
next prev parent reply other threads:[~2012-12-13 2:43 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-12 13:31 [RFC PATCH v2 0/6] sched: packing small tasks Vincent Guittot
2012-12-12 13:31 ` RFC PATCH v2 1/6] Revert "sched: introduce temporary FAIR_GROUP_SCHED dependency for load-tracking" Vincent Guittot
2012-12-12 13:31 ` [PATCH 2/6] sched: add a new SD SHARE_POWERLINE flag for sched_domain Vincent Guittot
2012-12-13 2:24 ` Alex Shi
2012-12-13 8:53 ` Vincent Guittot
2012-12-12 13:31 ` [RFC PATCH v2 3/6] sched: pack small tasks Vincent Guittot
2012-12-13 2:17 ` Alex Shi
2012-12-13 2:43 ` Alex Shi [this message]
2012-12-13 10:11 ` Vincent Guittot
2012-12-13 14:25 ` Alex Shi
2012-12-13 14:53 ` Vincent Guittot
2012-12-13 15:48 ` Vincent Guittot
2012-12-14 1:46 ` Alex Shi
2012-12-14 9:33 ` Vincent Guittot
2012-12-16 7:12 ` Alex Shi
2012-12-17 9:40 ` Vincent Guittot
2012-12-17 15:24 ` Alex Shi
2012-12-18 9:53 ` Vincent Guittot
2012-12-18 11:29 ` Alex Shi
2012-12-14 4:45 ` Mike Galbraith
2012-12-14 6:36 ` Alex Shi
2012-12-14 7:45 ` Mike Galbraith
2012-12-14 7:57 ` Alex Shi
2012-12-14 10:43 ` Vincent Guittot
2012-12-15 6:40 ` Mike Galbraith
2012-12-17 3:13 ` Alex Shi
2012-12-21 5:47 ` Namhyung Kim
2012-12-21 8:53 ` Vincent Guittot
2012-12-21 8:59 ` Vincent Guittot
2012-12-12 13:31 ` [RFC PATCH v2 4/6] sched: secure access to other CPU statistics Vincent Guittot
2012-12-12 13:31 ` [RFC PATCH v2 5/6] sched: pack the idle load balance Vincent Guittot
2012-12-12 13:31 ` [RFC PATCH v2 6/6] ARM: sched: clear SD_SHARE_POWERLINE 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=50C940E8.2020001@intel.com \
--to=alex.shi@intel.com \
--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 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).