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 22:25:22 +0800 [thread overview]
Message-ID: <50C9E552.1010600@intel.com> (raw)
In-Reply-To: <CAKfTPtB9iz1ePsS+juQVRhuWREYB1duGWRJT7ya8XBXPhC-mkw@mail.gmail.com>
On 12/13/2012 06:11 PM, Vincent Guittot wrote:
> On 13 December 2012 03:17, Alex Shi <alex.shi@intel.com> 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.
>
> The buddy CPU should probably not be the same for all 64 LCPU it
> depends on where it's worth packing small tasks
Do you have further ideas for buddy cpu on such example?
>
> Which kind of sched_domain configuration have you for such system ?
> and how many sched_domain level have you ?
it is general X86 domain configuration. with 4 levels,
sibling/core/cpu/numa.
>
next prev parent reply other threads:[~2012-12-13 14:25 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
2012-12-13 10:11 ` Vincent Guittot
2012-12-13 14:25 ` Alex Shi [this message]
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=50C9E552.1010600@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).