Re: [PATCH 8/15] sched: Add parameter sched_mn_power_savings tocontrol MN domain sched policy

[Andreas Herrmann]

On Mon, Aug 24, 2009 at 05:45:14PM +0200, Peter Zijlstra wrote:
> On Mon, 2009-08-24 at 21:02 +0530, Vaidyanathan Srinivasan wrote:
> > * Peter Zijlstra <peterz@xxxxxxxxxxxxx> [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@xxxxxxx>
> > > > ---
> > > 
> > > > +#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.
> 
> Well, I prefer a single sched_power knob that either goes on or off.

IMHO all options that are selectable at the moment have to map to that
single knob. One user might want to fill one socket for power savings
but still want to balance tasks between the internal nodes. Another
user wants to have highest possible power savings and likes to see all
threads utilized before another core is used even if the FPU/cache or
whatsoever are shared between threads on the same core.

> A user really isn't interested in exploring a 3^3 configuration space
> {PERF, POWER, POWER-WAKE-BALANCE} x {SMT, MC, MN} in order to find what
> works best.

Why not just give the average user some hints what he should select on
his machine but still let power users decide themselves what best fits
their purpose and provide means/knobs to select what they want?

> > 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.

> > 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.
> 
> Ah, right, that got lost in my inbox :/ Let me go read those too.
> 
> > 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.

> Yes, apparently AMD is going to put multiple nodes in a single socket,
> not sure how they do that, Andreas do these chips have multiple memory
> busses?

In contrast to current AMD processors (supporting two DRAM channels
per socket), Magny-Cours (new package type) has four DRAM channels.

> I was thinking chips were pin constrained and wouldn't add a whole
> second memory interface to the package, but what do I know...

For the two new channels of a Magny-Cours processor of course
additional pins are required.


Regards,

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/