From: Andreas Herrmann <andreas.herrmann3@amd.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, Gautham Shenoy <ego@in.ibm.com>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Dipankar Sarma <dipankar@in.ibm.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
"svaidy@linux.vnet.ibm.com" <svaidy@linux.vnet.ibm.com>,
Arun R Bharadwaj <arun@linux.vnet.ibm.com>
Subject: Re: [PATCH 8/15] sched: Add parameter sched_mn_power_savings to control MN domain sched policy
Date: Tue, 25 Aug 2009 08:24:32 +0200 [thread overview]
Message-ID: <20090825062432.GB20811@alberich.amd.com> (raw)
In-Reply-To: <1251125778.7538.268.camel@twins>
On Mon, Aug 24, 2009 at 04:56:18PM +0200, Peter Zijlstra wrote:
> On Thu, 2009-08-20 at 15:39 +0200, Andreas Herrmann wrote:
> > Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
> > ---
>
> > +#ifdef CONFIG_SCHED_MN
> > + if (!err && mc_capable())
> > + err = sysfs_create_file(&cls->kset.kobj,
> > + &attr_sched_mn_power_savings.attr);
> > +#endif
>
> *sigh* another crappy sysfs file
>
> Guys, can't we come up with anything better than sched_*_power_saving=n?
Thought this is a settled thing. At least there are already two
such parameters. So using the existing convention is an obvious
thing, no?
> This configuration space is _way_ too large, and now it gets even
> crazier.
I don't fully agree.
Having one control interface for each domain level is just one
approach. It gives the user full control of scheduling policies.
It just might have to be properly documented.
In another mail Vaidy mentioned that
"at some point we wanted to change the interface to
sched_power_savings=N and and set the flags according to system
topology".
But how you'll decide at which domain level you have to do power
savings scheduling?
Using sched_mn_power_savings=1 is quite different from
sched_smt_power_savings=1. Probably, the most power you save if you
switch on power saving scheduling on each domain level. I.e. first
filling threads of one core, then filling all cores on one internal
node, then filling all internal nodes of one socket.
But for performance reasons a user might just want to use power
savings in the MN domain. How you'd allow the user to configure that
with just one interface? Passing the domain level to
sched_power_savings, e.g. sched_power_savings=MC instead of the power
saving level?
Besides that, don't we have to keep the user-interface stable, i.e.
stick to sched_smt_power_savings and sched_mc_power_savings?
Regards,
Andreas
--
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany
Research | Geschäftsführer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München
(OSRC) | Registergericht München, HRB Nr. 43632
next prev parent reply other threads:[~2009-08-25 6:25 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-20 13:12 [RFC][PATCH 0/15] sched: Fix scheduling for multi-node processors Andreas Herrmann
2009-08-20 13:15 ` [PATCH 1/15] x86, sched: Add config option for multi-node CPU scheduling Andreas Herrmann
2009-08-21 13:50 ` Valdis.Kletnieks
2009-08-24 8:49 ` Andreas Herrmann
2009-08-20 13:34 ` [PATCH 2/15] sched, x86: Provide initializer for MN scheduling domain, define MN level Andreas Herrmann
2009-08-20 13:34 ` [PATCH 3/15] sched: Add cpumask to be used when building MN domain Andreas Herrmann
2009-08-20 13:35 ` [PATCH 4/15] sched: Define per CPU variables and cpu_to_group function for " Andreas Herrmann
2009-08-20 13:36 ` [PATCH 5/15] sched: Add function to build MN sched domain Andreas Herrmann
2009-08-20 13:37 ` [PATCH 6/15] sched: Add support for MN domain in build_sched_groups Andreas Herrmann
2009-08-20 13:38 ` [PATCH 7/15] sched: Activate build of MN domains Andreas Herrmann
2009-08-20 13:39 ` [PATCH 8/15] sched: Add parameter sched_mn_power_savings to control MN domain sched policy Andreas Herrmann
2009-08-24 14:56 ` Peter Zijlstra
2009-08-24 15:32 ` Vaidyanathan Srinivasan
2009-08-24 15:45 ` Peter Zijlstra
2009-08-25 7:52 ` Andreas Herrmann
2009-08-25 7:50 ` Andreas Herrmann
2009-08-25 6:24 ` Andreas Herrmann [this message]
2009-08-25 6:41 ` Peter Zijlstra
2009-08-25 8:38 ` Andreas Herrmann
2009-08-26 9:30 ` Gautham R Shenoy
2009-08-27 12:47 ` Andreas Herrmann
2009-08-20 13:40 ` [PATCH 9/15] sched: Check sched_mn_power_savings when setting flags for CPU and MN domains Andreas Herrmann
2009-08-24 14:57 ` Peter Zijlstra
2009-08-25 9:34 ` Gautham R Shenoy
2009-08-26 10:01 ` Gautham R Shenoy
2009-08-20 13:41 ` [PATCH 10/15] sched: Check for sched_mn_power_savings when doing load balancing Andreas Herrmann
2009-08-24 15:03 ` Peter Zijlstra
2009-08-24 15:40 ` Vaidyanathan Srinivasan
2009-08-25 8:00 ` Andreas Herrmann
2009-08-20 13:41 ` [PATCH 11/15] sched: Pass unlimited __cpu_power information to upper domain level groups Andreas Herrmann
2009-08-24 15:21 ` Peter Zijlstra
2009-08-24 16:44 ` Balbir Singh
2009-08-24 17:26 ` Peter Zijlstra
2009-08-24 18:19 ` Balbir Singh
2009-08-25 7:11 ` Peter Zijlstra
2009-08-25 8:04 ` Balbir Singh
2009-08-25 8:30 ` Peter Zijlstra
2009-08-25 8:51 ` Andreas Herrmann
2009-08-20 13:42 ` [PATCH 12/15] sched: Allow NODE domain to be parent of MC instead of CPU domain Andreas Herrmann
2009-08-24 15:32 ` Peter Zijlstra
2009-08-25 8:55 ` Andreas Herrmann
2009-08-20 13:43 ` [PATCH 13/15] sched: Detect child domain of NUMA (aka NODE) domain Andreas Herrmann
2009-08-24 15:34 ` Peter Zijlstra
2009-08-25 9:13 ` Andreas Herrmann
2009-08-20 13:45 ` [PATCH 14/15] sched: Conditionally limit __cpu_power when child sched domain has type NODE Andreas Herrmann
2009-08-24 15:35 ` Peter Zijlstra
2009-08-25 9:19 ` Andreas Herrmann
2009-08-20 13:46 ` [PATCH 15/15] x86: Fix cpu_coregroup_mask to return correct cpumask on multi-node processors Andreas Herrmann
2009-08-24 15:36 ` Peter Zijlstra
2009-08-24 18:21 ` Ingo Molnar
2009-08-25 10:13 ` Andreas Herrmann
2009-08-25 10:36 ` Ingo Molnar
2009-08-27 13:18 ` Andreas Herrmann
2009-08-25 9:31 ` Andreas Herrmann
2009-08-25 9:55 ` Peter Zijlstra
2009-08-25 10:20 ` Ingo Molnar
2009-08-25 10:24 ` Andreas Herrmann
2009-08-25 10:28 ` Ingo Molnar
2009-08-25 10:35 ` Peter Zijlstra
2009-08-27 15:42 ` Andreas Herrmann
2009-08-27 15:25 ` Andreas Herrmann
2009-08-28 10:39 ` Peter Zijlstra
2009-08-28 12:03 ` Andreas Herrmann
2009-08-28 12:50 ` Peter Zijlstra
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=20090825062432.GB20811@alberich.amd.com \
--to=andreas.herrmann3@amd.com \
--cc=arun@linux.vnet.ibm.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=dipankar@in.ibm.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=svaidy@linux.vnet.ibm.com \
--cc=vatsa@in.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®