lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090825062432.GB20811@alberich.amd.com>
Date:	Tue, 25 Aug 2009 08:24:32 +0200
From:	Andreas Herrmann <andreas.herrmann3@....com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	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>,
	"svaidy@...ux.vnet.ibm.com" <svaidy@...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 04:56:18PM +0200, Peter Zijlstra wrote:
> 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?

Thought this is a settled thing. At least there are already two
such parameters. So using the existing convention is an obvious
thing, no?
 
> This configuration space is _way_ too large, and now it gets even
> crazier.

I don't fully agree.

Having one control interface for each domain level is just one
approach. It gives the user full control of scheduling policies.
It just might have to be properly documented.

In another mail Vaidy mentioned that

  "at some point we wanted to change the interface to
   sched_power_savings=N and and set the flags according to system
   topology".

But how you'll decide at which domain level you have to do power
savings scheduling?

Using sched_mn_power_savings=1 is quite different from
sched_smt_power_savings=1. Probably, the most power you save if you
switch on power saving scheduling on each domain level. I.e. first
filling threads of one core, then filling all cores on one internal
node, then filling all internal nodes of one socket.

But for performance reasons a user might just want to use power
savings in the MN domain. How you'd allow the user to configure that
with just one interface? Passing the domain level to
sched_power_savings, e.g.  sched_power_savings=MC instead of the power
saving level?

Besides that, don't we have to keep the user-interface stable, i.e.
stick to sched_smt_power_savings and sched_mc_power_savings?


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

Powered by Openwall GNU/*/Linux Powered by OpenVZ