From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Peter Zijlstra <peterz@infradead.org>, Yuyang Du <yuyang.du@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [RFC PATCH 07/16 v3] Init Workload Consolidation flags in sched_domain
Date: Mon, 09 Jun 2014 18:56:17 +0100 [thread overview]
Message-ID: <5395F541.60604@arm.com> (raw)
In-Reply-To: <20140603121416.GH30445@twins.programming.kicks-ass.net>
... turned out that probably the cc list was too big for lkml. Dropping
all the individual email addresses on CC.
... it seems that this message hasn't made it to the list. Apologies to
everyone on To: and Cc: receiving it again.
On 03/06/14 13:14, Peter Zijlstra wrote:
> On Fri, May 30, 2014 at 02:36:03PM +0800, Yuyang Du wrote:
>> Workload Consolidation can be enabled/disabled on the fly. This patchset
>> enables MC and CPU domain WC by default.
>>
>> To enable CPU WC (SD_WORKLOAD_CONSOLIDATION=0x8000):
>>
>> sysctl -w kernel.sched_domain.cpuX.domainY.flags += 0x8000
>>
>> To disable CPU WC:
>>
>> sysctl -w kernel.sched_domain.cpuX.domainY.flags -= 0x8000
>>
>> Signed-off-by: Yuyang Du <yuyang.du@intel.com>
>> ---
>> include/linux/topology.h | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/include/linux/topology.h b/include/linux/topology.h
>> index 7062330..ebc339c3 100644
>> --- a/include/linux/topology.h
>> +++ b/include/linux/topology.h
>> @@ -102,12 +102,14 @@ int arch_update_cpu_topology(void);
>> | 0*SD_SERIALIZE \
>> | 0*SD_PREFER_SIBLING \
>> | arch_sd_sibling_asym_packing() \
>> + | 0*SD_WORKLOAD_CONSOLIDATION \
>> , \
>> .last_balance = jiffies, \
>> .balance_interval = 1, \
>> .smt_gain = 1178, /* 15% */ \
>> .max_newidle_lb_cost = 0, \
>> .next_decay_max_lb_cost = jiffies, \
>> + .consolidating_coeff = 0, \
>> }
>> #endif
>> #endif /* CONFIG_SCHED_SMT */
>> @@ -134,11 +136,13 @@ int arch_update_cpu_topology(void);
>> | 0*SD_SHARE_CPUPOWER \
>> | 1*SD_SHARE_PKG_RESOURCES \
>> | 0*SD_SERIALIZE \
>> + | 1*SD_WORKLOAD_CONSOLIDATION \
>> , \
>> .last_balance = jiffies, \
>> .balance_interval = 1, \
>> .max_newidle_lb_cost = 0, \
>> .next_decay_max_lb_cost = jiffies, \
>> + .consolidating_coeff = 180, \
>> }
>> #endif
>> #endif /* CONFIG_SCHED_MC */
>> @@ -167,11 +171,13 @@ int arch_update_cpu_topology(void);
>> | 0*SD_SHARE_PKG_RESOURCES \
>> | 0*SD_SERIALIZE \
>> | 1*SD_PREFER_SIBLING \
>> + | 1*SD_WORKLOAD_CONSOLIDATION \
>> , \
>> .last_balance = jiffies, \
>> .balance_interval = 1, \
>> .max_newidle_lb_cost = 0, \
>> .next_decay_max_lb_cost = jiffies, \
>> + .consolidating_coeff = 180, \
>> }
>> #endif
>
> What tree are you working against, non of that exists anymore. Also, you
> cannot unconditionally set this.
>
Hi Yuyang,
I'm running these patches on my ARM TC2 on top of
kernel/git/torvalds/linux.git (v3.15-rc7-79-gfe45736f4134). There're
considerable changes in the area of sched domain setup since Vincent's
patchset 'rework sched_domain topology description' (destined for v3.16)
which you can find on kernel/git/tip/tip.git .
Why did you make SD_WORKLOAD_CONSOLIDATION controllable via sysctl? All
the other SD flags are set during setup. Your top_flag_domain() function
takes care of figuring out what is the highest sd level this is set on
during load-balance but I can't find any good reason to do it this way
other then for testing purposes?
Setting SD_WORKLOAD_CONSOLIDATION (which is probably a behavioural flag
rather than a topology description related one) on a certain sd level
requires you to also think about its implications in sd_init() and in sd
degenerate functionality.
-- Dietmar
next prev parent reply other threads:[~2014-06-09 17:56 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-30 6:35 [RFC PATCH 00/16 v3] A new CPU load metric for power-efficient scheduler: CPU ConCurrency Yuyang Du
2014-05-30 6:35 ` [RFC PATCH 01/16 v3] Remove update_rq_runnable_avg Yuyang Du
2014-05-30 6:35 ` [RFC PATCH 02/16 v3] Define and initialize CPU ConCurrency in struct rq Yuyang Du
2014-05-30 6:35 ` [RFC PATCH 03/16 v3] How CC accrues with run queue change and time Yuyang Du
2014-06-03 12:12 ` Peter Zijlstra
2014-05-30 6:36 ` [RFC PATCH 04/16 v3] CPU CC update period is changeable via sysctl Yuyang Du
2014-05-30 6:36 ` [RFC PATCH 05/16 v3] Update CPU CC in fair Yuyang Du
2014-05-30 6:36 ` [RFC PATCH 06/16 v3] Add Workload Consolidation fields in struct sched_domain Yuyang Du
2014-05-30 6:36 ` [RFC PATCH 07/16 v3] Init Workload Consolidation flags in sched_domain Yuyang Du
2014-06-03 12:14 ` Peter Zijlstra
2014-06-09 17:56 ` Dietmar Eggemann [this message]
2014-06-09 21:18 ` Yuyang Du
2014-06-10 11:52 ` Dietmar Eggemann
2014-06-10 18:09 ` Yuyang Du
2014-06-11 9:27 ` Dietmar Eggemann
2014-05-30 6:36 ` [RFC PATCH 08/16 v3] Write CPU topology info for Workload Consolidation fields " Yuyang Du
2014-05-30 6:36 ` [RFC PATCH 09/16 v3] Define and allocate a per CPU local cpumask for Workload Consolidation Yuyang Du
2014-06-03 12:15 ` Peter Zijlstra
2014-05-30 6:36 ` [RFC PATCH 10/16 v3] Workload Consolidation APIs Yuyang Du
2014-06-03 12:22 ` Peter Zijlstra
2014-05-30 6:36 ` [RFC PATCH 11/16 v3] Make wakeup bias threshold changeable via sysctl Yuyang Du
2014-06-03 12:23 ` Peter Zijlstra
2014-05-30 6:36 ` [RFC PATCH 12/16 v3] Bias select wakee than waker in WAKE_AFFINE Yuyang Du
2014-06-03 12:24 ` Peter Zijlstra
2014-05-30 6:36 ` [RFC PATCH 13/16 v3] Intercept wakeup/fork/exec load balancing Yuyang Du
2014-06-03 12:27 ` Peter Zijlstra
2014-06-03 23:46 ` Yuyang Du
2014-05-30 6:36 ` [RFC PATCH 14/16 v3] Intercept idle balancing Yuyang Du
2014-05-30 6:36 ` [RFC PATCH 15/16 v3] Intercept periodic nohz " Yuyang Du
2014-05-30 6:36 ` [RFC PATCH 16/16 v3] Intercept periodic load balancing Yuyang Du
2014-06-09 17:30 ` [RFC PATCH 00/16 v3] A new CPU load metric for power-efficient scheduler: CPU ConCurrency Morten Rasmussen
[not found] ` <20140609164848.GB29593@e103034-lin>
2014-06-09 21:23 ` Yuyang Du
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=5395F541.60604@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=yuyang.du@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 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.