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]
Date:	Wed, 13 May 2009 19:12:51 +0530
From:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Suresh B Siddha <suresh.b.siddha@...el.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	Arjan van de Ven <arjan@...radead.org>,
	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>,
	Gregory Haskins <gregory.haskins@...il.com>,
	Mike Galbraith <efault@....de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Arun Bharadwaj <arun@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH v2 0/2] Saving power by cpu
	evacuationsched_max_capacity_pct=n

* Peter Zijlstra <a.p.zijlstra@...llo.nl> [2009-05-13 15:14:57]:

> On Wed, 2009-05-13 at 18:41 +0530, Vaidyanathan Srinivasan wrote:
> 
> > * Peter Zijlstra wanted more justifications for throttling at the core
> >   level.  Throttling may be a resource management problem rather than
> >   scheduler/load balancer
> 
> No, I mandate that it be thermal management. Any other reason and you've
> got a NAK.

Hi Peter,

Yes, I understand your objection.  Your want throttling to be done for
the purpose of thermal management only.  The primary purpose for
throttling should be thermal management (power savings may be
a side-effect)

What I meant in the above comment was that the implementation for
throttling could be solved using resource management framework,
cpuset/cgroup rather than biasing the load balancer to avoid work on
a particular core.

I am open to ideas for a clean and easy framework for core level
throttling.

Thanks,
Vaidy


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