From: Yuyang Du <yuyang.du@intel.com>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
"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: Tue, 10 Jun 2014 05:18:20 +0800 [thread overview]
Message-ID: <20140609211820.GA5361@intel.com> (raw)
In-Reply-To: <5395F541.60604@arm.com>
On Mon, Jun 09, 2014 at 06:56:17PM +0100, Dietmar Eggemann wrote:
Thanks, Dietmar.
> 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 .
>
Yeah, PeterZ pointed it out. It was on top of mainline not tip.
> Why did you make SD_WORKLOAD_CONSOLIDATION controllable via sysctl? All
> the other SD flags are set during setup.
>
I don't understand. Any flag or parameter in sched_domain can be modified
on-the-fly after booting via sysctl. The SD_XXX_INIT is a template to make
the sched_domain initialization easier, IIUC.
Yes, I should not unconditionally enable SD_WORKLOAD_CONSOLIDATION in MC
and CPU domain (pointed out by PeterZ), but I did so for the purpose of
testing this patchset at this moment. Eventually, this flag should not be
turned on for any domain by default for many reasons, not to mention CPU
topology is getting more diverse/complex.
I just checked Vincent's "rework sched_domain topology description". The
general picture for init sched_domain does not change. If you work on top
of tip tree, you can simply skip this patch (0007), and after booting
enable SD_WORKLOAD_CONSOLIDATION by:
sysctl -w kernel.sched_domain.cpuX.domainY.flags += 0x8000
sysctl -w kernel.sched_domain.cpu0.domain1.consolidating_coeff=180
sysctl -w kernel.sched_cc_wakeup_threshold=80
> 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?
Any flag is used for testing whether it is set on or not when encountering
it, including the flags in sched_domain for load balancing, this is why flag
is called flag. My flag is any excpetion?
Thanks,
Yuyang
next prev parent reply other threads:[~2014-06-10 5:22 UTC|newest]
Thread overview: 31+ 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
2014-06-09 21:18 ` Yuyang Du [this message]
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
[not found] ` <20140609164848.GB29593@e103034-lin>
2014-06-09 21:23 ` [RFC PATCH 00/16 v3] A new CPU load metric for power-efficient scheduler: CPU ConCurrency 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=20140609211820.GA5361@intel.com \
--to=yuyang.du@intel.com \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@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).