[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090825075055.GA15389@alberich.amd.com>
Date: Tue, 25 Aug 2009 09:50:55 +0200
From: Andreas Herrmann <andreas.herrmann3@....com>
To: Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
CC: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
linux-kernel@...r.kernel.org, Gautham Shenoy <ego@...ibm.com>,
Srivatsa Vaddagiri <vatsa@...ibm.com>,
Dipankar Sarma <dipankar@...ibm.com>,
Balbir Singh <balbir@...ux.vnet.ibm.com>,
Arun R Bharadwaj <arun@...ux.vnet.ibm.com>
Subject: Re: [PATCH 8/15] sched: Add parameter sched_mn_power_savings to
control MN domain sched policy
On Mon, Aug 24, 2009 at 09:02:29PM +0530, Vaidyanathan Srinivasan wrote:
> * Peter Zijlstra <peterz@...radead.org> [2009-08-24 16:56:18]:
>
> > On Thu, 2009-08-20 at 15:39 +0200, Andreas Herrmann wrote:
> > > Signed-off-by: Andreas Herrmann <andreas.herrmann3@....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?
> >
> > This configuration space is _way_ too large, and now it gets even
> > crazier.
>
> Hi Peter and Andreas,
>
> Actually we had sched_power_savings and related simplifications, but
> that did not really simplify the interface.
>
> As for this mulit-node MN stuff, Gautham had posted a better solution
> to propagate the sched_mc flags without need for new sysfs file and
> related changes.
For Magny-Cours it might be sufficient to just propagate the sched_mc
flags into the MN domain. But then the MC domain shouldn't use the
sched_mc power saving flag (for performance reasons). But I don't know
what other multi-node CPUs we will have in the future. So on an
abstract level power savings scheduling in sched_mc is not equal to
power savings scheduling on sched_mn.
> Please take a look at: http://lkml.org/lkml/2009/3/31/137 and
> http://lkml.org/lkml/2009/3/31/142 which actually degenerates the
> domain.
>
> However Andreas's requirement seem to indicate multiple nodes within
> a single socket. I did not yet completely understand that topology.
> Some for of smart degeneration may save an additional tunable here.
I doubt that a "form of smart degeneration" would help. You want to
have sched_groups for each internal node and you most likely always
want to do balancing between those two. But in case of power saving
scheduling you want to utilize an entire socket before you deploy
another socket. Hence I think, in the end, "smart degeneration" would
rather mean some sort of hackery which won't make the code easier.
> Thanks for pointing me to this patch.
Dito.
I'll have a look at your power savings simplifications asap.
Thanks,
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
--
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