linux-kernel - Re: [RFC PATCH v5 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]

Message-ID: <20081214200843.GO5457@dirshya.in.ibm.com>
Date:	Mon, 15 Dec 2008 01:38:43 +0530
From:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
To:	Pavel Machek <pavel@...e.cz>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Suresh B Siddha <suresh.b.siddha@...el.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	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>,
	Gregory Haskins <gregory.haskins@...il.com>
Subject: Re: [RFC PATCH v5 0/7] Tunable sched_mc_power_savings=n

* Pavel Machek <pavel@...e.cz> [1970-01-01 01:13:43]:

> 
> > Results:
> > --------
> > 
> > Basic functionality of the code has not changed and the power vs
> > performance benefits for kernbench are similar to the ones posted
> > earlier.
> > 
> > KERNBENCH Runs: make -j4 on a x86 8 core, dual socket quad core cpu
> > package system
> > 
> > SchedMC Run Time     Package Idle    Energy  Power
> > 0	81.28	     52.43% 53.53%  1.00x J 1.00y W
> > 1	80.71	     37.35% 68.91%  0.96x J 0.97y W
> > 2	76.05	     23.81% 82.65%  0.92x J 0.98y W
> > 
> > *** This is RFC code and not for inclusion ***
> 
> Hmm, so it makes it compile faster _and_ it saves power? Why to keep
> it tunable at all if it is win-win? Or are there other benchmarks?

Hi Pavel,

The performance and power gain depends on the nature of the
application.  If the processor cache is large enough, then
consolidation improves cache sharing and makes the system finish the
job faster.  I would expect applications with larger cache foot print
and no data sharing may experience degradation in performance.

I am open to suggestion on any interesting workload that should be
tested.  I have tested ebizzy and SPECjbb for power savings.  I am
also looking forward to test reports from others having different
system topology and processor power saving features.

The idea behind the tunable is to have power saving as higher priority
in scheduling relative to performance.  At higher sched_mc(2) settings
(aggressive power save mode), we should save power even if there is
a slight degradation in application performance.  If we save power and
improve performance, then it is a best case scenario.  However I would
expect certain workloads to sacrifice performance for the power
consumption.

At sched_mc = 0 the scheduler would not optimise for power savings
and provide maximum performance for any application.

Kernel compile is a representative workload where my additional
optimisations for sched_mc=2 improves over the default sched_mc=1
implementation in the kernel.

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