public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Suresh Siddha <suresh.b.siddha@intel.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: "svaidy@linux.vnet.ibm.com" <svaidy@linux.vnet.ibm.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	"Siddha, Suresh B" <suresh.b.siddha@intel.com>,
	"Pallipadi, Venkatesh" <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>,
	Andi Kleen <andi@firstfloor.org>,
	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: Mon, 8 Sep 2008 18:20:40 -0700	[thread overview]
Message-ID: <20080909012039.GO14481@linux-os.sc.intel.com> (raw)
In-Reply-To: <1220882169.12278.23.camel@twins.programming.kicks-ass.net>

On Mon, Sep 08, 2008 at 06:56:09AM -0700, Peter Zijlstra wrote:
> On Mon, 2008-09-08 at 19:18 +0530, Vaidyanathan Srinivasan wrote:
> > * Peter Zijlstra <a.p.zijlstra@chello.nl> [2008-09-08 15:25:46]:
> >
> > > May I again ask to first clean up the current power saving code before
> > > stacking more on top of it?
> >
> > :) I understand that you have asked for two things with respect to the
> > current power save balance code:
> >
> > 1. Detailed documentation
> 
> Preferably in the form of in-code comments and code structure, this
> Documentation/* stuff always gets lost on me.

Peter, Almost every if() stmt/basic block  in the power savings code has
comments around it. And also power-savings code is 50 lines (mostly comments)
in 320 lines of that function.

> But I also prefer to get rid of that power savings tweak in
> cpu_coregroup_map().

Why? Based on the power vs perf, we wanted to construct topologies
differently. Reason for the complexity is, in some of the Intel cpu's,
while the cores share the same package they have different last level caches.
So for performance, we want to differentiate based on last level caches
and for power, we want to consolidate based on the package information.

> But above all, readable code ;-)
> 
> find_busiest_group() is the stuff of nightmares.

power-savings code is very small part of that nightmare :) That code
became complex over years with HT, smp-nice etc.

I haven't been following recent sched changes. I can take a look at it
and see what I can do to better organize find_busiest_group()

thanks,
suresh

  reply	other threads:[~2008-09-09  1:22 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 [this message]
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

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=20080909012039.GO14481@linux-os.sc.intel.com \
    --to=suresh.b.siddha@intel.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=svaidy@linux.vnet.ibm.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