[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 9 Sep 2008 19:03:24 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Suresh Siddha <suresh.b.siddha@...el.com>,
"svaidy@...ux.vnet.ibm.com" <svaidy@...ux.vnet.ibm.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@...el.com>,
Ingo Molnar <mingo@...e.hu>,
Dipankar Sarma <dipankar@...ibm.com>,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
Vatsa <vatsa@...ux.vnet.ibm.com>,
Gautham R Shenoy <ego@...ibm.com>,
Andi Kleen <andi@...stfloor.org>,
David Collier-Brown <davecb@....com>,
Tim Connors <tconnors@...ro.swin.edu.au>,
Max Krasnyansky <maxk@...lcomm.com>
Subject: Re: [RFC PATCH v2 0/7] Tunable sched_mc_power_savings=n
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists