linux-kernel - Re: [PATCH] x86,sched: Fix sched_smt_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:	Mon, 9 Jan 2012 21:33:17 +0530
From:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Youquan Song <youquan.song@...el.com>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, tglx@...utronix.de,
	hpa@...or.com, akpm@...ux-foundation.org, stable@...r.kernel.org,
	suresh.b.siddha@...el.com, arjan@...ux.intel.com,
	len.brown@...el.com, anhua.xu@...el.com, chaohong.guo@...el.com,
	Youquan Song <youquan.song@...ux.intel.com>,
	Paul Turner <pjt@...gle.com>
Subject: Re: [PATCH] x86,sched: Fix sched_smt_power_savings totally broken

* Peter Zijlstra <peterz@...radead.org> [2012-01-09 15:35:07]:

> On Mon, 2012-01-09 at 16:30 +0530, Vaidyanathan Srinivasan wrote:
> > Lets combine the MC/SMT options and create sched_powersavings={0,1,2}
> > That will make it only one sysfs knob without any dependencies.
> > 
> Is there really any sane rationale to keep the 1/2 thing? Why not have a
> single boolean knob that says performance/power?

Yes, based on the architecture and topology, we do have two sweet
spots for power vs performance trade offs.  The first level should be
to reduce power savings with marginal performance impact and second
one will be to go for the most aggressive power savings.

The first one should generally be recommended as default to have
a right balance between performance and power savings, while the
second one should be used for reducing power consumption on
unimportant workloads or under certain constraints.

Some example policies:

sched_powersavings=1:

        Enable consolidation at MC level

sched_powersavings=2:

        Enable aggressive consolidation at MC level and SMT level if
        available. In case arch can benefit from cross node
        consolidation, then enable it.

Having the above simple split in policy will enable wide adoption
where the first level can be a recommended default.  Having just
a boolean enable/disable will mean the end-user will have to decide
when to turn on and later off for best workload experience.

Just similar to cpufreq policy of performance, ondemand and powersave.
They have their unique use cases and this design choice helps us ship
ondemand as default.

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