linux-kernel - [RFC PATCH v1 00/11] Create fast idle path for short idle periods

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: <1499650721-5928-1-git-send-email-aubrey.li@intel.com>
Date:   Mon, 10 Jul 2017 09:38:30 +0800
From:   Aubrey Li <aubrey.li@...el.com>
To:     tglx@...utronix.de, peterz@...radead.org, len.brown@...el.com,
        rjw@...ysocki.net, ak@...ux.intel.com, tim.c.chen@...ux.intel.com,
        arjan@...ux.intel.com, paulmck@...ux.vnet.ibm.com,
        yang.zhang.wz@...il.com
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        Aubrey Li <aubrey.li@...ux.intel.com>
Subject: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

From: Aubrey Li <aubrey.li@...ux.intel.com>

Under some latency intensive workloads, short idle periods occurs very
common, so that idle entry and exit path starts to dominate. It's important
to optimize them for the short idle period pattern. A fast idle path proposal
is introduced here for this purpose.

This proposal uses two factors in idle menu governor to predict the next
idle period. The one is energy break even point, the other is repeatable
interval detector. These two factors are generic to all arches.

If the next idle period is longer than the predefined threshold, that means
the next idle will be a long idle, then the idle thread will enter the
original normal idle path. Otherwise, the coming idle will be a short idle,
the idle thread will enter the fast idle path, which is supposed to enter
and exit faster than the normal path.

The predicted idle period is already computed in the cpuidle framework, so
pass it directly to menu governor to select the next c-state. Menu governor
does not need to compute again.

We measured 3%~5% improvemnt in disk IO workload, and 8%~20% improvement in
network workload. 

Aubrey Li (11):
  sched/idle: create a fast path for short idle periods
  cpuidle: attach cpuidle governor statistics to the per-CPU device
  cpuidle: introduce cpuidle governor for idle prediction
  sched/idle: make the fast idle path for short idle periods
  cpuidle: update idle statistics before cpuidle governor
  timers: keep sleep length updated as needed
  cpuidle: make idle residency update more generic
  cpuidle: menu: remove reduplicative implementation
  cpuidle: menu: feed cpuidle prediction to menu governor
  cpuidle: update cpuidle governor when needed
  sched/idle: Add a tuning knob to allow changing fast idle threshold

 drivers/cpuidle/cpuidle.c        | 241 +++++++++++++++++++++++++++++++++++++++
 drivers/cpuidle/governors/menu.c | 192 +------------------------------
 include/linux/cpuidle.h          |  35 ++++++
 include/linux/sched/sysctl.h     |   1 +
 kernel/sched/idle.c              |  81 +++++++++++--
 kernel/sysctl.c                  |  10 ++
 kernel/time/tick-sched.c         |   3 +
 7 files changed, 366 insertions(+), 197 deletions(-)

-- 
2.7.4