mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
	"svaidy@linux.vnet.ibm.com" <svaidy@linux.vnet.ibm.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	"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: Tue, 9 Sep 2008 19:03:24 +1000	[thread overview]
Message-ID: <200809091903.24836.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <1220948723.18239.1091.camel@twins.programming.kicks-ass.net>

On Tuesday 09 September 2008 18:25, Peter Zijlstra wrote:
> On Tue, 2008-09-09 at 17:59 +1000, Nick Piggin wrote:

> > But it's all per-cpu, so you'd have to iterate down other CPU's child
> > domains. Which may get dirtied by that CPU. So you get cacheline
> > bounces.
>
> Humm, are you saying each cpu has its own domain tree? My understanding
> was that its a global structure, eg. given:
>
>    domain[0-1]
>
> domain[0] domain[1]
>
> cpu0's parent domain is the same instance as cpu1's.

I haven't looked recently, but that's how I wrote it. Has that changed?


> > You also lose flexibility (although nobody really takes full advantage
> > of it) of totally arbitrary topology on a per-cpu basis.
>
> Afaict the only flexibility you loose is that you cannot make groups
> larger/smaller than the child domain - which given that the whole
> premesis of the groups existence is that the inner-group balancing
> should be done by the level below - doesn't make sense anyway.

But you *also* cannot have per-cpu domain trees.


> > > So my idea was to ditch the groups and just iterate over the child
> > > domains.
> >
> > I'm not saying you couldn't do it (reasonably well -- cacheline bouncing
> > might be a problem if you propose to traverse other CPU's domains), but
> > what exactly does that gain you?
>
> Those cacheline bounces could be mitigated by splitting sched_domain
> into two parts with a cacheline aligned dummy and keep the rarely
> modified data separate from the frequently modified data.

You could.


> As to the gains - a graph walk with a single type seems more elegant to
> me.

It's fundamentally two different things anyway though. I don't
see any theoretical improvement, and it definitely wouldn't
improve the practical side much if any because the biggest problem
I don't think is the simple walks themselves but the calculations
and stuff.

If it can yield something clearly better that is impossible using
domains and groups, I could change my mind.


  reply	other threads:[~2008-09-09  9:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-08 13:14 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 [this message]
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=200809091903.24836.nickpiggin@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --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=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

Powered by JetHome