linux-kernel - [PATCH RFC 0/7] scheduler-driven cpu frequency scaling

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 Oct 2014 23:07:24 -0700
From:	Mike Turquette <mturquette@...aro.org>
To:	peterz@...radead.org, mingo@...nel.org
Cc:	linux-kernel@...r.kernel.org, preeti@...ux.vnet.ibm.com,
	Morten.Rasmussen@....com, kamalesh@...ux.vnet.ibm.com,
	riel@...hat.com, efault@....de, nicolas.pitre@...aro.org,
	linaro-kernel@...ts.linaro.org, daniel.lezcano@...aro.org,
	dietmar.eggemann@....com, pjt@...gle.com, bsegall@...gle.com,
	vincent.guittot@...aro.org, patches@...aro.org,
	tuukka.tikkanen@...aro.org, amit.kucheria@...aro.org,
	Mike Turquette <mturquette@...aro.org>
Subject: [PATCH RFC 0/7] scheduler-driven cpu frequency scaling

This series demonstrates cpu frequency scaling via a simple policy
driven by the scheduler. Specifically the policy evaluates cpu frequency
when cpu utilization is updated from enqueue_task_fair and
dequeue_task_fair. The policy itself uses a simple up/down threshold
scheme using the same 80%/20% cpu utilization boundaries that are used
by default in the ondemand cpufreq governor.

This series is not intended for merging, but instead to ignite some
discussion around scheduler-driven cpu frequency selection. Of
particular interest to me is the policy itself and how it might
integrate with task placement in CFS's load_balance. Additionally I'd
like to ask the scheduler experts about which call sites in CFS are
right for evaluating cpu frequency selection; maybe
{en,de}queue_task_fair are not such a good idea?

The messiest part of this series is the cpumask stuff, where I tried to
track which cpus have updated statistics in the case of a sched_entity
which contains several other sched_entities that are spread across cpus.
As discussed at Linux Plumbers Conference 2014, I will replace this
complexity with simpler logic that ignores scheduler cgroups in the next
version. In any case I am posting the code I have now.

This code is experiemental and bugs are Guaranteed.

These patches are based on the scale invariance series from Morten[0].
The variables names in this RFC will doubtless change once that work is
rebased onto Vincent's series[1].

[0] http://lkml.kernel.org/r/<1411403047-32010-1-git-send-email-morten.rasmussen@....com>
[1] http://lkml.kernel.org/r/<1412684017-16595-1-git-send-email-vincent.guittot@...aro.org>

Mike Turquette (6):
  sched: cfs: declare capacity_of in sched.h
  sched: fair: add usage_util_of helper
  cpufreq: add per-governor private data
  sched: cfs: cpu frequency scaling arch functions
  sched: cfs: cpu frequency scaling based on task placement
  sched: energy_model: simple cpu frequency scaling policy

Morten Rasmussen (1):
  sched: Make energy awareness a sched feature

 drivers/cpufreq/Kconfig     |  21 +++
 include/linux/cpufreq.h     |   6 +
 kernel/sched/Makefile       |   1 +
 kernel/sched/energy_model.c | 341 ++++++++++++++++++++++++++++++++++++++++++++
 kernel/sched/fair.c         |  69 ++++++++-
 kernel/sched/features.h     |   6 +
 kernel/sched/sched.h        |   3 +
 7 files changed, 445 insertions(+), 2 deletions(-)
 create mode 100644 kernel/sched/energy_model.c

-- 
1.8.3.2

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