linux-kernel - [PATCH 0/4] CFS idle injection

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

Message-Id: <1447444387-23525-1-git-send-email-jacob.jun.pan@linux.intel.com>
Date:	Fri, 13 Nov 2015 11:53:03 -0800
From:	Jacob Pan <jacob.jun.pan@...ux.intel.com>
To:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <john.stultz@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>
Cc:	Arjan van de Ven <arjan@...ux.intel.com>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
	Len Brown <len.brown@...el.com>,
	Rafael Wysocki <rafael.j.wysocki@...el.com>,
	Eduardo Valentin <edubezval@...il.com>,
	Paul Turner <pjt@...gle.com>,
	Jacob Pan <jacob.jun.pan@...ux.intel.com>
Subject: [PATCH 0/4] CFS idle injection

We are entering a very power and thermal constrained environment. Often
we have more horsepower than we can use due to these limits. But
on the other side we all demand performance when needed. The reserved
performance headroom does not come free. To conserve energy, more and
more SoC blocks can be power gated at runtime. However, randomly
scheduled idle time on individual CPU may not result in good power
saving in that the common circuits such as memory controller can only be
in the low power state when all cores are in idle at the same time.

Frequency-Voltage scaling presents a good solution but its efficiency
is limited to certain range.

In general, only synchronized idle will allow SoC to enter the
deepest power states. For most modern processors, deep idle power is
nearly negligible to the peak running power. This implies if we can
duty cycle the CPU between running and the deepest idle state, we can
scale performance and power almost linearly. Combined with the most
efficient frequency point, idle injection presents a way to cap power
efficiently.

Intel powerclamp driver was introduced a while ago to address the
problem but is broken in the sense of turning off idle ticks in the
forced idle period. https://lkml.org/lkml/2014/12/18/369

It was suggested to replace the current kthread play idle loop with a
timer based runqueue throttling scheme. I finally got around to
implement this and code looks much simpler and more effective.

Test results were presented at LinuxCon where data/graph can be seen
from slides #18 and later.
http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_Japan_2015_idle_injection1_0.pdf

RFC discussions are here.
https://lkml.org/lkml/2015/11/2/756

Thanks,

Jacob

Jacob Pan (4):
  ktime: add a roundup function
  timer: relax tick stop in idle entry
  sched: introduce synchronized idle injection
  sched: add trace event for idle injection

 include/linux/ktime.h        |  10 ++
 include/linux/sched.h        |  16 ++
 include/linux/sched/sysctl.h |   5 +
 include/trace/events/sched.h |  25 +++
 init/Kconfig                 |  10 ++
 kernel/sched/fair.c          | 356 ++++++++++++++++++++++++++++++++++++++++++-
 kernel/sched/sched.h         |  54 ++++++-
 kernel/sysctl.c              |  21 +++
 kernel/time/tick-sched.c     |   2 +-
 9 files changed, 493 insertions(+), 6 deletions(-)

-- 
1.9.1

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