linux-kernel - Re: [RFC PATCH v2 0/7] Tunable sched_mc_power

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] [day] [month] [year] [list]

Date:	Wed, 10 Sep 2008 19:15:44 +0530
From:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Suresh B Siddha <suresh.b.siddha@...el.com>,
	Venkatesh Pallipadi <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>,
	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

* Andi Kleen <andi@...stfloor.org> [2008-09-08 15:58:34]:

> > 1. Detailed documentation
> 
> Messy code cannot be really made good with documentation. It's
> not that your patches are that messy, it's more that it makes
> something already overcomplicated even worse.
> 
> > 2. Cleanup the group_min and group_leader stuff in
> >    find_busiest_group()
> 
> I think one issue is that there are general too many special cases
> that completely change the algorithm especially for power saving.
> Perhaps it would make sense to refactor the code a bit and then
> use different high level code paths for those?  I assume that
> would make it all simpler and easier to understand.

Hi Andi,

I will try to refactor the code and see if it can look cleaner.  Power
saving balance is actually just a corner case in general load_balance.
We will have to do default load_balance for performance each time we
enter this section of the scheduler, except when certain complex
conditions are met and we see an opportunity to save power. When that
window of opportunity to save power exist, the code will take
a different path and do things that will normally not be done by the
default load balancer logic.

I think we can split the statistics (load) computation part and the
decision part to separate functions and call the power save balance
conditions first and if there is no opportunity to save power, then
recommend the default load balancing decision.

> 
> The other alternative would be to dynamically change the domains
> so that a generic graph walker without knowledge of power savings
> could DTRT in all cases. But I assume that would be much harder.

This option may not work because we will have to change the decision
only when a power saving opportunity exist.  Hence more often the
power save balance code should just fall through into the default
balancer.  Splitting them this way may add duplicate code in both the
paths.

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