From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Suresh B Siddha <suresh.b.siddha@intel.com>,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
Ingo Molnar <mingo@elte.hu>, Dipankar Sarma <dipankar@in.ibm.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
Vatsa <vatsa@linux.vnet.ibm.com>,
Gautham R Shenoy <ego@in.ibm.com>,
David Collier-Brown <davecb@sun.com>,
Tim Connors <tconnors@astro.swin.edu.au>,
Max Krasnyansky <maxk@qualcomm.com>
Subject: Re: [RFC PATCH v2 0/7] Tunable sched_mc_power_savings=n
Date: Wed, 10 Sep 2008 19:15:44 +0530 [thread overview]
Message-ID: <20080910134544.GA17984@dirshya.in.ibm.com> (raw)
In-Reply-To: <20080908135834.GH26079@one.firstfloor.org>
* Andi Kleen <andi@firstfloor.org> [2008-09-08 15:58:34]:
> > 1. Detailed documentation
>
> Messy code cannot be really made good with documentation. It's
> not that your patches are that messy, it's more that it makes
> something already overcomplicated even worse.
>
> > 2. Cleanup the group_min and group_leader stuff in
> > find_busiest_group()
>
> I think one issue is that there are general too many special cases
> that completely change the algorithm especially for power saving.
> Perhaps it would make sense to refactor the code a bit and then
> use different high level code paths for those? I assume that
> would make it all simpler and easier to understand.
Hi Andi,
I will try to refactor the code and see if it can look cleaner. Power
saving balance is actually just a corner case in general load_balance.
We will have to do default load_balance for performance each time we
enter this section of the scheduler, except when certain complex
conditions are met and we see an opportunity to save power. When that
window of opportunity to save power exist, the code will take
a different path and do things that will normally not be done by the
default load balancer logic.
I think we can split the statistics (load) computation part and the
decision part to separate functions and call the power save balance
conditions first and if there is no opportunity to save power, then
recommend the default load balancing decision.
>
> The other alternative would be to dynamically change the domains
> so that a generic graph walker without knowledge of power savings
> could DTRT in all cases. But I assume that would be much harder.
This option may not work because we will have to change the decision
only when a power saving opportunity exist. Hence more often the
power save balance code should just fall through into the default
balancer. Splitting them this way may add duplicate code in both the
paths.
--Vaidy
prev parent reply other threads:[~2008-09-10 13:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-08 13:14 [RFC PATCH v2 0/7] Tunable sched_mc_power_savings=n Vaidyanathan Srinivasan
2008-09-08 13:16 ` [RFC PATCH v2 1/7] sched: arch_reinit_sched_domains() must destroy domains to force rebuild Vaidyanathan Srinivasan
2008-09-08 13:17 ` [RFC PATCH v2 2/7] sched: Fix __load_balance_iterator() for cfq with only one task Vaidyanathan Srinivasan
2008-09-08 13:18 ` [RFC PATCH v2 3/7] sched: Framework for sched_mc/smt_power_savings=N Vaidyanathan Srinivasan
2008-09-08 13:20 ` [RFC PATCH v2 4/7] sched: favour lower logical cpu number for sched_mc balance Vaidyanathan Srinivasan
2008-09-08 13:21 ` [RFC PATCH v2 5/7] sched: nominate preferred wakeup cpu Vaidyanathan Srinivasan
2008-09-08 13:21 ` Peter Zijlstra
2008-09-08 13:43 ` Vaidyanathan Srinivasan
2008-09-08 13:22 ` [RFC PATCH v2 6/7] sched: bias task wakeups to preferred semi-idle packages Vaidyanathan Srinivasan
2008-09-08 13:23 ` [RFC PATCH v2 7/7] sched: activate active load balancing in new idle cpus Vaidyanathan Srinivasan
2008-09-08 13:25 ` [RFC PATCH v2 0/7] Tunable sched_mc_power_savings=n Peter Zijlstra
2008-09-08 13:48 ` Vaidyanathan Srinivasan
2008-09-08 13:56 ` Peter Zijlstra
2008-09-09 1:20 ` Suresh Siddha
2008-09-09 6:18 ` Peter Zijlstra
2008-09-09 6:31 ` Nick Piggin
2008-09-09 6:54 ` Peter Zijlstra
2008-09-09 7:59 ` Nick Piggin
2008-09-09 8:25 ` Peter Zijlstra
2008-09-09 9:03 ` Nick Piggin
2008-09-08 13:58 ` Andi Kleen
2008-09-10 13:45 ` Vaidyanathan Srinivasan [this message]
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=20080910134544.GA17984@dirshya.in.ibm.com \
--to=svaidy@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=andi@firstfloor.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=davecb@sun.com \
--cc=dipankar@in.ibm.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
--cc=tconnors@astro.swin.edu.au \
--cc=vatsa@linux.vnet.ibm.com \
--cc=venkatesh.pallipadi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox