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

Date:	Tue, 9 Sep 2008 16:31:48 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Suresh Siddha <suresh.b.siddha@...el.com>,
	"svaidy@...ux.vnet.ibm.com" <svaidy@...ux.vnet.ibm.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	"Pallipadi, Venkatesh" <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>,
	Andi Kleen <andi@...stfloor.org>,
	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

On Tuesday 09 September 2008 16:18, Peter Zijlstra wrote:

> I've been looking at the history of that function - it started out quite
> readable - but has, over the years, grown into a monstrosity.

I agree it is terrible, and subsequent "features" weren't really properly
written or integrated into the sched domains idea.


> Then there is this whole sched_group stuff, which I intent to have a
> hard look at, afaict its unneeded and we can iterate over the
> sub-domains just as well.

What sub-domains? The domains-minus-groups are just a graph (in existing
setup code AFAIK just a line) of cpumasks. You have to group because you
want enough control for example not to pull load from an unusually busy
CPU from one group if it's load should actually be spread out over a
smaller domain (ie. probably other CPUs within the group we're looking at).

It would be nice if you could make it simpler of course, but I just don't
understand you or maybe you thought of some other way to solve this or
why it doesn't matter...


> Finally, we should move all this stuff into sched_fair and get rid of
> that iterator interface and fix up all nr_running etc.. usages to refer
> to cfs.nr_running and similar.
>
> Then there is the idea Andi proposed, splitting up the performance and
> power balancer into two separate functions, something that is worth
> looking into imho.

That's what *I* suggested. Before it even went in. Of course there was no
attempt made at all and it went in despite my reservations, but what's new
:)
--
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/