License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* Completely Fair Scheduling (CFS) Class (SCHED_NORMAL/SCHED_BATCH)
|
|
|
|
*
|
|
|
|
* Copyright (C) 2007 Red Hat, Inc., Ingo Molnar <mingo@redhat.com>
|
|
|
|
*
|
|
|
|
* Interactivity improvements by Mike Galbraith
|
|
|
|
* (C) 2007 Mike Galbraith <efault@gmx.de>
|
|
|
|
*
|
|
|
|
* Various enhancements by Dmitry Adamushko.
|
|
|
|
* (C) 2007 Dmitry Adamushko <dmitry.adamushko@gmail.com>
|
|
|
|
*
|
|
|
|
* Group scheduling enhancements by Srivatsa Vaddagiri
|
|
|
|
* Copyright IBM Corporation, 2007
|
|
|
|
* Author: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
|
|
|
|
*
|
|
|
|
* Scaled math optimizations by Thomas Gleixner
|
|
|
|
* Copyright (C) 2007, Thomas Gleixner <tglx@linutronix.de>
|
2007-08-25 16:41:53 +00:00
|
|
|
*
|
|
|
|
* Adaptive scheduling granularity, math enhancements by Peter Zijlstra
|
2015-11-16 10:08:45 +00:00
|
|
|
* Copyright (C) 2007 Red Hat, Inc., Peter Zijlstra
|
2007-07-09 16:51:58 +00:00
|
|
|
*/
|
2018-03-03 11:20:47 +00:00
|
|
|
#include "sched.h"
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
#include <trace/events/sched.h>
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
2007-08-25 16:41:53 +00:00
|
|
|
* Targeted preemption latency for CPU-bound tasks:
|
2007-07-09 16:51:58 +00:00
|
|
|
*
|
2007-08-25 16:41:53 +00:00
|
|
|
* NOTE: this latency value is not the same as the concept of
|
2007-10-15 15:00:14 +00:00
|
|
|
* 'timeslice length' - timeslices in CFS are of variable length
|
|
|
|
* and have no persistent notion like in traditional, time-slice
|
|
|
|
* based scheduling concepts.
|
2007-07-09 16:51:58 +00:00
|
|
|
*
|
2007-10-15 15:00:14 +00:00
|
|
|
* (to see the precise effective timeslice length of your workload,
|
|
|
|
* run vmstat and monitor the context-switches (cs) field)
|
2016-11-23 06:37:00 +00:00
|
|
|
*
|
|
|
|
* (default: 6ms * (1 + ilog(ncpus)), units: nanoseconds)
|
2007-07-09 16:51:58 +00:00
|
|
|
*/
|
2016-11-23 06:37:00 +00:00
|
|
|
unsigned int sysctl_sched_latency = 6000000ULL;
|
2018-11-10 07:52:02 +00:00
|
|
|
static unsigned int normalized_sysctl_sched_latency = 6000000ULL;
|
2007-10-15 15:00:02 +00:00
|
|
|
|
2009-11-30 11:16:47 +00:00
|
|
|
/*
|
|
|
|
* The initial- and re-scaling of tunables is configurable
|
|
|
|
*
|
|
|
|
* Options are:
|
2016-11-23 06:37:00 +00:00
|
|
|
*
|
|
|
|
* SCHED_TUNABLESCALING_NONE - unscaled, always *1
|
|
|
|
* SCHED_TUNABLESCALING_LOG - scaled logarithmical, *1+ilog(ncpus)
|
|
|
|
* SCHED_TUNABLESCALING_LINEAR - scaled linear, *ncpus
|
|
|
|
*
|
|
|
|
* (default SCHED_TUNABLESCALING_LOG = *(1+ilog(ncpus))
|
2009-11-30 11:16:47 +00:00
|
|
|
*/
|
2016-11-23 06:37:00 +00:00
|
|
|
enum sched_tunable_scaling sysctl_sched_tunable_scaling = SCHED_TUNABLESCALING_LOG;
|
2009-11-30 11:16:47 +00:00
|
|
|
|
2007-10-15 15:00:02 +00:00
|
|
|
/*
|
2007-11-09 21:39:37 +00:00
|
|
|
* Minimal preemption granularity for CPU-bound tasks:
|
2016-11-23 06:37:00 +00:00
|
|
|
*
|
2010-10-14 07:09:13 +00:00
|
|
|
* (default: 0.75 msec * (1 + ilog(ncpus)), units: nanoseconds)
|
2007-10-15 15:00:02 +00:00
|
|
|
*/
|
2018-11-10 07:52:02 +00:00
|
|
|
unsigned int sysctl_sched_min_granularity = 750000ULL;
|
|
|
|
static unsigned int normalized_sysctl_sched_min_granularity = 750000ULL;
|
2007-08-25 16:41:53 +00:00
|
|
|
|
|
|
|
/*
|
2016-11-23 06:37:00 +00:00
|
|
|
* This value is kept at sysctl_sched_latency/sysctl_sched_min_granularity
|
2007-11-09 21:39:37 +00:00
|
|
|
*/
|
2010-09-12 06:14:52 +00:00
|
|
|
static unsigned int sched_nr_latency = 8;
|
2007-11-09 21:39:37 +00:00
|
|
|
|
|
|
|
/*
|
2009-09-09 13:41:37 +00:00
|
|
|
* After fork, child runs first. If set to 0 (default) then
|
2007-11-09 21:39:37 +00:00
|
|
|
* parent will (try to) run first.
|
2007-08-25 16:41:53 +00:00
|
|
|
*/
|
2009-09-09 13:41:37 +00:00
|
|
|
unsigned int sysctl_sched_child_runs_first __read_mostly;
|
2007-07-09 16:51:58 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* SCHED_OTHER wake-up granularity.
|
|
|
|
*
|
|
|
|
* This option delays the preemption effects of decoupled workloads
|
|
|
|
* and reduces their over-scheduling. Synchronous workloads will still
|
|
|
|
* have immediate wakeup/sleep latencies.
|
2016-11-23 06:37:00 +00:00
|
|
|
*
|
|
|
|
* (default: 1 msec * (1 + ilog(ncpus)), units: nanoseconds)
|
2007-07-09 16:51:58 +00:00
|
|
|
*/
|
2018-11-10 07:52:02 +00:00
|
|
|
unsigned int sysctl_sched_wakeup_granularity = 1000000UL;
|
|
|
|
static unsigned int normalized_sysctl_sched_wakeup_granularity = 1000000UL;
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2016-11-23 06:37:00 +00:00
|
|
|
const_debug unsigned int sysctl_sched_migration_cost = 500000UL;
|
2007-10-15 15:00:18 +00:00
|
|
|
|
2016-11-22 20:23:53 +00:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* For asym packing, by default the lower numbered CPU has higher priority.
|
2016-11-22 20:23:53 +00:00
|
|
|
*/
|
|
|
|
int __weak arch_asym_cpu_priority(int cpu)
|
|
|
|
{
|
|
|
|
return -cpu;
|
|
|
|
}
|
2018-11-25 22:41:05 +00:00
|
|
|
|
|
|
|
/*
|
2019-06-04 07:01:52 +00:00
|
|
|
* The margin used when comparing utilization with CPU capacity.
|
2018-11-25 22:41:05 +00:00
|
|
|
*
|
|
|
|
* (default: ~20%)
|
|
|
|
*/
|
2019-06-04 07:01:52 +00:00
|
|
|
#define fits_capacity(cap, max) ((cap) * 1280 < (max) * 1024)
|
|
|
|
|
2016-11-22 20:23:53 +00:00
|
|
|
#endif
|
|
|
|
|
2011-07-21 16:43:30 +00:00
|
|
|
#ifdef CONFIG_CFS_BANDWIDTH
|
|
|
|
/*
|
|
|
|
* Amount of runtime to allocate from global (tg) to local (per-cfs_rq) pool
|
|
|
|
* each time a cfs_rq requests quota.
|
|
|
|
*
|
|
|
|
* Note: in the case that the slice exceeds the runtime remaining (either due
|
|
|
|
* to consumption or the quota being specified to be smaller than the slice)
|
|
|
|
* we will always only issue the remaining available time.
|
|
|
|
*
|
2016-11-23 06:37:00 +00:00
|
|
|
* (default: 5 msec, units: microseconds)
|
|
|
|
*/
|
|
|
|
unsigned int sysctl_sched_cfs_bandwidth_slice = 5000UL;
|
2011-07-21 16:43:30 +00:00
|
|
|
#endif
|
|
|
|
|
2013-04-19 19:10:50 +00:00
|
|
|
static inline void update_load_add(struct load_weight *lw, unsigned long inc)
|
|
|
|
{
|
|
|
|
lw->weight += inc;
|
|
|
|
lw->inv_weight = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void update_load_sub(struct load_weight *lw, unsigned long dec)
|
|
|
|
{
|
|
|
|
lw->weight -= dec;
|
|
|
|
lw->inv_weight = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void update_load_set(struct load_weight *lw, unsigned long w)
|
|
|
|
{
|
|
|
|
lw->weight = w;
|
|
|
|
lw->inv_weight = 0;
|
|
|
|
}
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
/*
|
|
|
|
* Increase the granularity value when there are more CPUs,
|
|
|
|
* because with more CPUs the 'effective latency' as visible
|
|
|
|
* to users decreases. But the relationship is not linear,
|
|
|
|
* so pick a second-best guess by going with the log2 of the
|
|
|
|
* number of CPUs.
|
|
|
|
*
|
|
|
|
* This idea comes from the SD scheduler of Con Kolivas:
|
|
|
|
*/
|
2015-05-15 19:05:42 +00:00
|
|
|
static unsigned int get_update_sysctl_factor(void)
|
2011-10-25 08:00:11 +00:00
|
|
|
{
|
2015-05-15 19:05:42 +00:00
|
|
|
unsigned int cpus = min_t(unsigned int, num_online_cpus(), 8);
|
2011-10-25 08:00:11 +00:00
|
|
|
unsigned int factor;
|
|
|
|
|
|
|
|
switch (sysctl_sched_tunable_scaling) {
|
|
|
|
case SCHED_TUNABLESCALING_NONE:
|
|
|
|
factor = 1;
|
|
|
|
break;
|
|
|
|
case SCHED_TUNABLESCALING_LINEAR:
|
|
|
|
factor = cpus;
|
|
|
|
break;
|
|
|
|
case SCHED_TUNABLESCALING_LOG:
|
|
|
|
default:
|
|
|
|
factor = 1 + ilog2(cpus);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return factor;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void update_sysctl(void)
|
|
|
|
{
|
|
|
|
unsigned int factor = get_update_sysctl_factor();
|
|
|
|
|
|
|
|
#define SET_SYSCTL(name) \
|
|
|
|
(sysctl_##name = (factor) * normalized_sysctl_##name)
|
|
|
|
SET_SYSCTL(sched_min_granularity);
|
|
|
|
SET_SYSCTL(sched_latency);
|
|
|
|
SET_SYSCTL(sched_wakeup_granularity);
|
|
|
|
#undef SET_SYSCTL
|
|
|
|
}
|
|
|
|
|
|
|
|
void sched_init_granularity(void)
|
|
|
|
{
|
|
|
|
update_sysctl();
|
|
|
|
}
|
|
|
|
|
2013-11-18 17:27:06 +00:00
|
|
|
#define WMULT_CONST (~0U)
|
2011-10-25 08:00:11 +00:00
|
|
|
#define WMULT_SHIFT 32
|
|
|
|
|
2013-11-18 17:27:06 +00:00
|
|
|
static void __update_inv_weight(struct load_weight *lw)
|
|
|
|
{
|
|
|
|
unsigned long w;
|
|
|
|
|
|
|
|
if (likely(lw->inv_weight))
|
|
|
|
return;
|
|
|
|
|
|
|
|
w = scale_load_down(lw->weight);
|
|
|
|
|
|
|
|
if (BITS_PER_LONG > 32 && unlikely(w >= WMULT_CONST))
|
|
|
|
lw->inv_weight = 1;
|
|
|
|
else if (unlikely(!w))
|
|
|
|
lw->inv_weight = WMULT_CONST;
|
|
|
|
else
|
|
|
|
lw->inv_weight = WMULT_CONST / w;
|
|
|
|
}
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
/*
|
2013-11-18 17:27:06 +00:00
|
|
|
* delta_exec * weight / lw.weight
|
|
|
|
* OR
|
|
|
|
* (delta_exec * (weight * lw->inv_weight)) >> WMULT_SHIFT
|
|
|
|
*
|
2016-03-29 23:07:51 +00:00
|
|
|
* Either weight := NICE_0_LOAD and lw \e sched_prio_to_wmult[], in which case
|
2013-11-18 17:27:06 +00:00
|
|
|
* we're guaranteed shift stays positive because inv_weight is guaranteed to
|
|
|
|
* fit 32 bits, and NICE_0_LOAD gives another 10 bits; therefore shift >= 22.
|
|
|
|
*
|
|
|
|
* Or, weight =< lw.weight (because lw.weight is the runqueue weight), thus
|
|
|
|
* weight/lw.weight <= 1, and therefore our shift will also be positive.
|
2011-10-25 08:00:11 +00:00
|
|
|
*/
|
2013-11-18 17:27:06 +00:00
|
|
|
static u64 __calc_delta(u64 delta_exec, unsigned long weight, struct load_weight *lw)
|
2011-10-25 08:00:11 +00:00
|
|
|
{
|
2013-11-18 17:27:06 +00:00
|
|
|
u64 fact = scale_load_down(weight);
|
|
|
|
int shift = WMULT_SHIFT;
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2013-11-18 17:27:06 +00:00
|
|
|
__update_inv_weight(lw);
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2013-11-18 17:27:06 +00:00
|
|
|
if (unlikely(fact >> 32)) {
|
|
|
|
while (fact >> 32) {
|
|
|
|
fact >>= 1;
|
|
|
|
shift--;
|
|
|
|
}
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
2019-11-08 13:15:59 +00:00
|
|
|
fact = mul_u32_u32(fact, lw->inv_weight);
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2013-11-18 17:27:06 +00:00
|
|
|
while (fact >> 32) {
|
|
|
|
fact >>= 1;
|
|
|
|
shift--;
|
|
|
|
}
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2013-11-18 17:27:06 +00:00
|
|
|
return mul_u64_u32_shr(delta_exec, fact, shift);
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
const struct sched_class fair_sched_class;
|
2008-10-17 17:27:03 +00:00
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/**************************************************************
|
|
|
|
* CFS operations on generic schedulable entities:
|
|
|
|
*/
|
|
|
|
|
2007-10-15 15:00:03 +00:00
|
|
|
#ifdef CONFIG_FAIR_GROUP_SCHED
|
2009-07-24 10:25:30 +00:00
|
|
|
static inline struct task_struct *task_of(struct sched_entity *se)
|
|
|
|
{
|
2016-09-20 20:34:51 +00:00
|
|
|
SCHED_WARN_ON(!entity_is_task(se));
|
2009-07-24 10:25:30 +00:00
|
|
|
return container_of(se, struct task_struct, se);
|
|
|
|
}
|
|
|
|
|
2008-04-19 17:45:00 +00:00
|
|
|
/* Walk up scheduling entities hierarchy */
|
|
|
|
#define for_each_sched_entity(se) \
|
|
|
|
for (; se; se = se->parent)
|
|
|
|
|
|
|
|
static inline struct cfs_rq *task_cfs_rq(struct task_struct *p)
|
|
|
|
{
|
|
|
|
return p->se.cfs_rq;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* runqueue on which this entity is (to be) queued */
|
|
|
|
static inline struct cfs_rq *cfs_rq_of(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
return se->cfs_rq;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* runqueue "owned" by this group */
|
|
|
|
static inline struct cfs_rq *group_cfs_rq(struct sched_entity *grp)
|
|
|
|
{
|
|
|
|
return grp->my_q;
|
|
|
|
}
|
|
|
|
|
2019-06-04 11:14:55 +00:00
|
|
|
static inline void cfs_rq_tg_path(struct cfs_rq *cfs_rq, char *path, int len)
|
|
|
|
{
|
|
|
|
if (!path)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (cfs_rq && task_group_is_autogroup(cfs_rq->tg))
|
|
|
|
autogroup_path(cfs_rq->tg, path, len);
|
|
|
|
else if (cfs_rq && cfs_rq->tg->css.cgroup)
|
|
|
|
cgroup_path(cfs_rq->tg->css.cgroup, path, len);
|
|
|
|
else
|
|
|
|
strlcpy(path, "(null)", len);
|
|
|
|
}
|
|
|
|
|
2019-01-30 05:22:47 +00:00
|
|
|
static inline bool list_add_leaf_cfs_rq(struct cfs_rq *cfs_rq)
|
2010-11-15 23:47:01 +00:00
|
|
|
{
|
2019-01-30 13:41:04 +00:00
|
|
|
struct rq *rq = rq_of(cfs_rq);
|
|
|
|
int cpu = cpu_of(rq);
|
|
|
|
|
|
|
|
if (cfs_rq->on_list)
|
2019-01-30 05:22:47 +00:00
|
|
|
return rq->tmp_alone_branch == &rq->leaf_cfs_rq_list;
|
2019-01-30 13:41:04 +00:00
|
|
|
|
|
|
|
cfs_rq->on_list = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure we either appear before our parent (if already
|
|
|
|
* enqueued) or force our parent to appear after us when it is
|
|
|
|
* enqueued. The fact that we always enqueue bottom-up
|
|
|
|
* reduces this to two cases and a special case for the root
|
|
|
|
* cfs_rq. Furthermore, it also means that we will always reset
|
|
|
|
* tmp_alone_branch either when the branch is connected
|
|
|
|
* to a tree or when we reach the top of the tree
|
|
|
|
*/
|
|
|
|
if (cfs_rq->tg->parent &&
|
|
|
|
cfs_rq->tg->parent->cfs_rq[cpu]->on_list) {
|
2010-11-15 23:47:05 +00:00
|
|
|
/*
|
2019-01-30 13:41:04 +00:00
|
|
|
* If parent is already on the list, we add the child
|
|
|
|
* just before. Thanks to circular linked property of
|
|
|
|
* the list, this means to put the child at the tail
|
|
|
|
* of the list that starts by parent.
|
2010-11-15 23:47:05 +00:00
|
|
|
*/
|
2019-01-30 13:41:04 +00:00
|
|
|
list_add_tail_rcu(&cfs_rq->leaf_cfs_rq_list,
|
|
|
|
&(cfs_rq->tg->parent->cfs_rq[cpu]->leaf_cfs_rq_list));
|
|
|
|
/*
|
|
|
|
* The branch is now connected to its tree so we can
|
|
|
|
* reset tmp_alone_branch to the beginning of the
|
|
|
|
* list.
|
|
|
|
*/
|
|
|
|
rq->tmp_alone_branch = &rq->leaf_cfs_rq_list;
|
2019-01-30 05:22:47 +00:00
|
|
|
return true;
|
2019-01-30 13:41:04 +00:00
|
|
|
}
|
2010-11-15 23:47:01 +00:00
|
|
|
|
2019-01-30 13:41:04 +00:00
|
|
|
if (!cfs_rq->tg->parent) {
|
|
|
|
/*
|
|
|
|
* cfs rq without parent should be put
|
|
|
|
* at the tail of the list.
|
|
|
|
*/
|
|
|
|
list_add_tail_rcu(&cfs_rq->leaf_cfs_rq_list,
|
|
|
|
&rq->leaf_cfs_rq_list);
|
|
|
|
/*
|
|
|
|
* We have reach the top of a tree so we can reset
|
|
|
|
* tmp_alone_branch to the beginning of the list.
|
|
|
|
*/
|
|
|
|
rq->tmp_alone_branch = &rq->leaf_cfs_rq_list;
|
2019-01-30 05:22:47 +00:00
|
|
|
return true;
|
2010-11-15 23:47:01 +00:00
|
|
|
}
|
2019-01-30 13:41:04 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The parent has not already been added so we want to
|
|
|
|
* make sure that it will be put after us.
|
|
|
|
* tmp_alone_branch points to the begin of the branch
|
|
|
|
* where we will add parent.
|
|
|
|
*/
|
|
|
|
list_add_rcu(&cfs_rq->leaf_cfs_rq_list, rq->tmp_alone_branch);
|
|
|
|
/*
|
|
|
|
* update tmp_alone_branch to points to the new begin
|
|
|
|
* of the branch
|
|
|
|
*/
|
|
|
|
rq->tmp_alone_branch = &cfs_rq->leaf_cfs_rq_list;
|
2019-01-30 05:22:47 +00:00
|
|
|
return false;
|
2010-11-15 23:47:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void list_del_leaf_cfs_rq(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
if (cfs_rq->on_list) {
|
2019-02-06 16:14:21 +00:00
|
|
|
struct rq *rq = rq_of(cfs_rq);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* With cfs_rq being unthrottled/throttled during an enqueue,
|
|
|
|
* it can happen the tmp_alone_branch points the a leaf that
|
|
|
|
* we finally want to del. In this case, tmp_alone_branch moves
|
|
|
|
* to the prev element but it will point to rq->leaf_cfs_rq_list
|
|
|
|
* at the end of the enqueue.
|
|
|
|
*/
|
|
|
|
if (rq->tmp_alone_branch == &cfs_rq->leaf_cfs_rq_list)
|
|
|
|
rq->tmp_alone_branch = cfs_rq->leaf_cfs_rq_list.prev;
|
|
|
|
|
2010-11-15 23:47:01 +00:00
|
|
|
list_del_rcu(&cfs_rq->leaf_cfs_rq_list);
|
|
|
|
cfs_rq->on_list = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-30 13:41:04 +00:00
|
|
|
static inline void assert_list_leaf_cfs_rq(struct rq *rq)
|
|
|
|
{
|
|
|
|
SCHED_WARN_ON(rq->tmp_alone_branch != &rq->leaf_cfs_rq_list);
|
|
|
|
}
|
|
|
|
|
2019-02-06 16:14:22 +00:00
|
|
|
/* Iterate thr' all leaf cfs_rq's on a runqueue */
|
|
|
|
#define for_each_leaf_cfs_rq_safe(rq, cfs_rq, pos) \
|
|
|
|
list_for_each_entry_safe(cfs_rq, pos, &rq->leaf_cfs_rq_list, \
|
|
|
|
leaf_cfs_rq_list)
|
2008-04-19 17:45:00 +00:00
|
|
|
|
|
|
|
/* Do the two (enqueued) entities belong to the same group ? */
|
2012-02-11 05:05:00 +00:00
|
|
|
static inline struct cfs_rq *
|
2008-04-19 17:45:00 +00:00
|
|
|
is_same_group(struct sched_entity *se, struct sched_entity *pse)
|
|
|
|
{
|
|
|
|
if (se->cfs_rq == pse->cfs_rq)
|
2012-02-11 05:05:00 +00:00
|
|
|
return se->cfs_rq;
|
2008-04-19 17:45:00 +00:00
|
|
|
|
2012-02-11 05:05:00 +00:00
|
|
|
return NULL;
|
2008-04-19 17:45:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct sched_entity *parent_entity(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
return se->parent;
|
|
|
|
}
|
|
|
|
|
2008-10-24 09:06:15 +00:00
|
|
|
static void
|
|
|
|
find_matching_se(struct sched_entity **se, struct sched_entity **pse)
|
|
|
|
{
|
|
|
|
int se_depth, pse_depth;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* preemption test can be made between sibling entities who are in the
|
|
|
|
* same cfs_rq i.e who have a common parent. Walk up the hierarchy of
|
|
|
|
* both tasks until we find their ancestors who are siblings of common
|
|
|
|
* parent.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* First walk up until both entities are at same depth */
|
2012-02-11 05:05:00 +00:00
|
|
|
se_depth = (*se)->depth;
|
|
|
|
pse_depth = (*pse)->depth;
|
2008-10-24 09:06:15 +00:00
|
|
|
|
|
|
|
while (se_depth > pse_depth) {
|
|
|
|
se_depth--;
|
|
|
|
*se = parent_entity(*se);
|
|
|
|
}
|
|
|
|
|
|
|
|
while (pse_depth > se_depth) {
|
|
|
|
pse_depth--;
|
|
|
|
*pse = parent_entity(*pse);
|
|
|
|
}
|
|
|
|
|
|
|
|
while (!is_same_group(*se, *pse)) {
|
|
|
|
*se = parent_entity(*se);
|
|
|
|
*pse = parent_entity(*pse);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-07-24 10:25:30 +00:00
|
|
|
#else /* !CONFIG_FAIR_GROUP_SCHED */
|
|
|
|
|
|
|
|
static inline struct task_struct *task_of(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
return container_of(se, struct task_struct, se);
|
|
|
|
}
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2008-04-19 17:45:00 +00:00
|
|
|
#define for_each_sched_entity(se) \
|
|
|
|
for (; se; se = NULL)
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2008-04-19 17:45:00 +00:00
|
|
|
static inline struct cfs_rq *task_cfs_rq(struct task_struct *p)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2008-04-19 17:45:00 +00:00
|
|
|
return &task_rq(p)->cfs;
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2008-04-19 17:45:00 +00:00
|
|
|
static inline struct cfs_rq *cfs_rq_of(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
struct task_struct *p = task_of(se);
|
|
|
|
struct rq *rq = task_rq(p);
|
|
|
|
|
|
|
|
return &rq->cfs;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* runqueue "owned" by this group */
|
|
|
|
static inline struct cfs_rq *group_cfs_rq(struct sched_entity *grp)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-06-04 11:14:55 +00:00
|
|
|
static inline void cfs_rq_tg_path(struct cfs_rq *cfs_rq, char *path, int len)
|
|
|
|
{
|
|
|
|
if (path)
|
|
|
|
strlcpy(path, "(null)", len);
|
|
|
|
}
|
|
|
|
|
2019-01-30 05:22:47 +00:00
|
|
|
static inline bool list_add_leaf_cfs_rq(struct cfs_rq *cfs_rq)
|
2010-11-15 23:47:01 +00:00
|
|
|
{
|
2019-01-30 05:22:47 +00:00
|
|
|
return true;
|
2010-11-15 23:47:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void list_del_leaf_cfs_rq(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2019-01-30 13:41:04 +00:00
|
|
|
static inline void assert_list_leaf_cfs_rq(struct rq *rq)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2019-02-06 16:14:22 +00:00
|
|
|
#define for_each_leaf_cfs_rq_safe(rq, cfs_rq, pos) \
|
|
|
|
for (cfs_rq = &rq->cfs, pos = NULL; cfs_rq; cfs_rq = pos)
|
2008-04-19 17:45:00 +00:00
|
|
|
|
|
|
|
static inline struct sched_entity *parent_entity(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2008-10-24 09:06:15 +00:00
|
|
|
static inline void
|
|
|
|
find_matching_se(struct sched_entity **se, struct sched_entity **pse)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2008-04-19 17:45:00 +00:00
|
|
|
#endif /* CONFIG_FAIR_GROUP_SCHED */
|
|
|
|
|
2012-03-21 20:07:16 +00:00
|
|
|
static __always_inline
|
2013-11-18 17:27:06 +00:00
|
|
|
void account_cfs_rq_runtime(struct cfs_rq *cfs_rq, u64 delta_exec);
|
2007-07-09 16:51:58 +00:00
|
|
|
|
|
|
|
/**************************************************************
|
|
|
|
* Scheduling class tree data structure manipulation methods:
|
|
|
|
*/
|
|
|
|
|
2013-03-12 19:12:24 +00:00
|
|
|
static inline u64 max_vruntime(u64 max_vruntime, u64 vruntime)
|
2007-10-15 15:00:07 +00:00
|
|
|
{
|
2013-03-12 19:12:24 +00:00
|
|
|
s64 delta = (s64)(vruntime - max_vruntime);
|
2007-10-15 15:00:11 +00:00
|
|
|
if (delta > 0)
|
2013-03-12 19:12:24 +00:00
|
|
|
max_vruntime = vruntime;
|
2007-10-15 15:00:07 +00:00
|
|
|
|
2013-03-12 19:12:24 +00:00
|
|
|
return max_vruntime;
|
2007-10-15 15:00:07 +00:00
|
|
|
}
|
|
|
|
|
2007-10-15 15:00:14 +00:00
|
|
|
static inline u64 min_vruntime(u64 min_vruntime, u64 vruntime)
|
2007-10-15 15:00:12 +00:00
|
|
|
{
|
|
|
|
s64 delta = (s64)(vruntime - min_vruntime);
|
|
|
|
if (delta < 0)
|
|
|
|
min_vruntime = vruntime;
|
|
|
|
|
|
|
|
return min_vruntime;
|
|
|
|
}
|
|
|
|
|
2009-07-16 10:32:27 +00:00
|
|
|
static inline int entity_before(struct sched_entity *a,
|
|
|
|
struct sched_entity *b)
|
|
|
|
{
|
|
|
|
return (s64)(a->vruntime - b->vruntime) < 0;
|
|
|
|
}
|
|
|
|
|
2008-10-24 09:06:13 +00:00
|
|
|
static void update_min_vruntime(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
2016-09-20 19:58:12 +00:00
|
|
|
struct sched_entity *curr = cfs_rq->curr;
|
2017-09-08 23:14:55 +00:00
|
|
|
struct rb_node *leftmost = rb_first_cached(&cfs_rq->tasks_timeline);
|
2016-09-20 19:58:12 +00:00
|
|
|
|
2008-10-24 09:06:13 +00:00
|
|
|
u64 vruntime = cfs_rq->min_vruntime;
|
|
|
|
|
2016-09-20 19:58:12 +00:00
|
|
|
if (curr) {
|
|
|
|
if (curr->on_rq)
|
|
|
|
vruntime = curr->vruntime;
|
|
|
|
else
|
|
|
|
curr = NULL;
|
|
|
|
}
|
2008-10-24 09:06:13 +00:00
|
|
|
|
2017-09-08 23:14:55 +00:00
|
|
|
if (leftmost) { /* non-empty tree */
|
|
|
|
struct sched_entity *se;
|
|
|
|
se = rb_entry(leftmost, struct sched_entity, run_node);
|
2008-10-24 09:06:13 +00:00
|
|
|
|
2016-09-20 19:58:12 +00:00
|
|
|
if (!curr)
|
2008-10-24 09:06:13 +00:00
|
|
|
vruntime = se->vruntime;
|
|
|
|
else
|
|
|
|
vruntime = min_vruntime(vruntime, se->vruntime);
|
|
|
|
}
|
|
|
|
|
2013-03-12 19:12:24 +00:00
|
|
|
/* ensure we never gain time by being placed backwards. */
|
2008-10-24 09:06:13 +00:00
|
|
|
cfs_rq->min_vruntime = max_vruntime(cfs_rq->min_vruntime, vruntime);
|
2011-04-05 15:23:48 +00:00
|
|
|
#ifndef CONFIG_64BIT
|
|
|
|
smp_wmb();
|
|
|
|
cfs_rq->min_vruntime_copy = cfs_rq->min_vruntime;
|
|
|
|
#endif
|
2008-10-24 09:06:13 +00:00
|
|
|
}
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* Enqueue an entity into the rb-tree:
|
|
|
|
*/
|
2007-10-15 15:00:14 +00:00
|
|
|
static void __enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2017-09-08 23:14:55 +00:00
|
|
|
struct rb_node **link = &cfs_rq->tasks_timeline.rb_root.rb_node;
|
2007-07-09 16:51:58 +00:00
|
|
|
struct rb_node *parent = NULL;
|
|
|
|
struct sched_entity *entry;
|
2017-09-08 23:14:55 +00:00
|
|
|
bool leftmost = true;
|
2007-07-09 16:51:58 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the right place in the rbtree:
|
|
|
|
*/
|
|
|
|
while (*link) {
|
|
|
|
parent = *link;
|
|
|
|
entry = rb_entry(parent, struct sched_entity, run_node);
|
|
|
|
/*
|
|
|
|
* We dont care about collisions. Nodes with
|
|
|
|
* the same key stay together.
|
|
|
|
*/
|
2011-07-20 12:46:59 +00:00
|
|
|
if (entity_before(se, entry)) {
|
2007-07-09 16:51:58 +00:00
|
|
|
link = &parent->rb_left;
|
|
|
|
} else {
|
|
|
|
link = &parent->rb_right;
|
2017-09-08 23:14:55 +00:00
|
|
|
leftmost = false;
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
rb_link_node(&se->run_node, parent, link);
|
2017-09-08 23:14:55 +00:00
|
|
|
rb_insert_color_cached(&se->run_node,
|
|
|
|
&cfs_rq->tasks_timeline, leftmost);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2007-10-15 15:00:14 +00:00
|
|
|
static void __dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2017-09-08 23:14:55 +00:00
|
|
|
rb_erase_cached(&se->run_node, &cfs_rq->tasks_timeline);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
struct sched_entity *__pick_first_entity(struct cfs_rq *cfs_rq)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2017-09-08 23:14:55 +00:00
|
|
|
struct rb_node *left = rb_first_cached(&cfs_rq->tasks_timeline);
|
2008-11-04 20:25:07 +00:00
|
|
|
|
|
|
|
if (!left)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return rb_entry(left, struct sched_entity, run_node);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2011-02-01 14:51:03 +00:00
|
|
|
static struct sched_entity *__pick_next_entity(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
struct rb_node *next = rb_next(&se->run_node);
|
|
|
|
|
|
|
|
if (!next)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return rb_entry(next, struct sched_entity, run_node);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef CONFIG_SCHED_DEBUG
|
2011-10-25 08:00:11 +00:00
|
|
|
struct sched_entity *__pick_last_entity(struct cfs_rq *cfs_rq)
|
2007-10-15 15:00:05 +00:00
|
|
|
{
|
2017-09-08 23:14:55 +00:00
|
|
|
struct rb_node *last = rb_last(&cfs_rq->tasks_timeline.rb_root);
|
2007-10-15 15:00:05 +00:00
|
|
|
|
2008-02-22 07:55:53 +00:00
|
|
|
if (!last)
|
|
|
|
return NULL;
|
2008-02-22 09:32:21 +00:00
|
|
|
|
|
|
|
return rb_entry(last, struct sched_entity, run_node);
|
2007-10-15 15:00:05 +00:00
|
|
|
}
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/**************************************************************
|
|
|
|
* Scheduling class statistics methods:
|
|
|
|
*/
|
|
|
|
|
2009-11-30 11:16:48 +00:00
|
|
|
int sched_proc_update_handler(struct ctl_table *table, int write,
|
2009-09-23 22:57:19 +00:00
|
|
|
void __user *buffer, size_t *lenp,
|
2007-11-09 21:39:37 +00:00
|
|
|
loff_t *ppos)
|
|
|
|
{
|
2009-09-23 22:57:19 +00:00
|
|
|
int ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
|
2015-05-15 19:05:42 +00:00
|
|
|
unsigned int factor = get_update_sysctl_factor();
|
2007-11-09 21:39:37 +00:00
|
|
|
|
|
|
|
if (ret || !write)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
sched_nr_latency = DIV_ROUND_UP(sysctl_sched_latency,
|
|
|
|
sysctl_sched_min_granularity);
|
|
|
|
|
2009-11-30 11:16:48 +00:00
|
|
|
#define WRT_SYSCTL(name) \
|
|
|
|
(normalized_sysctl_##name = sysctl_##name / (factor))
|
|
|
|
WRT_SYSCTL(sched_min_granularity);
|
|
|
|
WRT_SYSCTL(sched_latency);
|
|
|
|
WRT_SYSCTL(sched_wakeup_granularity);
|
|
|
|
#undef WRT_SYSCTL
|
|
|
|
|
2007-11-09 21:39:37 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#endif
|
2007-10-15 15:00:13 +00:00
|
|
|
|
2008-06-27 11:41:11 +00:00
|
|
|
/*
|
2008-10-17 17:27:04 +00:00
|
|
|
* delta /= w
|
2008-06-27 11:41:11 +00:00
|
|
|
*/
|
2013-11-18 17:27:06 +00:00
|
|
|
static inline u64 calc_delta_fair(u64 delta, struct sched_entity *se)
|
2008-06-27 11:41:11 +00:00
|
|
|
{
|
2008-10-17 17:27:04 +00:00
|
|
|
if (unlikely(se->load.weight != NICE_0_LOAD))
|
2013-11-18 17:27:06 +00:00
|
|
|
delta = __calc_delta(delta, NICE_0_LOAD, &se->load);
|
2008-06-27 11:41:11 +00:00
|
|
|
|
|
|
|
return delta;
|
|
|
|
}
|
|
|
|
|
2007-10-15 15:00:13 +00:00
|
|
|
/*
|
|
|
|
* The idea is to set a period in which each task runs once.
|
|
|
|
*
|
2012-08-08 14:16:04 +00:00
|
|
|
* When there are too many tasks (sched_nr_latency) we have to stretch
|
2007-10-15 15:00:13 +00:00
|
|
|
* this period because otherwise the slices get too small.
|
|
|
|
*
|
|
|
|
* p = (nr <= nl) ? l : l*nr/nl
|
|
|
|
*/
|
2007-10-15 15:00:04 +00:00
|
|
|
static u64 __sched_period(unsigned long nr_running)
|
|
|
|
{
|
2015-07-02 14:25:52 +00:00
|
|
|
if (unlikely(nr_running > sched_nr_latency))
|
|
|
|
return nr_running * sysctl_sched_min_granularity;
|
|
|
|
else
|
|
|
|
return sysctl_sched_latency;
|
2007-10-15 15:00:04 +00:00
|
|
|
}
|
|
|
|
|
2007-10-15 15:00:13 +00:00
|
|
|
/*
|
|
|
|
* We calculate the wall-time slice from the period by taking a part
|
|
|
|
* proportional to the weight.
|
|
|
|
*
|
2008-10-17 17:27:04 +00:00
|
|
|
* s = p*P[w/rw]
|
2007-10-15 15:00:13 +00:00
|
|
|
*/
|
2007-10-15 15:00:05 +00:00
|
|
|
static u64 sched_slice(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
2007-08-25 16:41:53 +00:00
|
|
|
{
|
2009-01-02 11:16:42 +00:00
|
|
|
u64 slice = __sched_period(cfs_rq->nr_running + !se->on_rq);
|
2008-10-17 17:27:04 +00:00
|
|
|
|
2009-01-02 11:16:42 +00:00
|
|
|
for_each_sched_entity(se) {
|
2009-01-15 16:17:15 +00:00
|
|
|
struct load_weight *load;
|
2009-06-16 08:35:12 +00:00
|
|
|
struct load_weight lw;
|
2009-01-15 16:17:15 +00:00
|
|
|
|
|
|
|
cfs_rq = cfs_rq_of(se);
|
|
|
|
load = &cfs_rq->load;
|
2008-10-17 17:27:04 +00:00
|
|
|
|
2009-01-02 11:16:42 +00:00
|
|
|
if (unlikely(!se->on_rq)) {
|
2009-06-16 08:35:12 +00:00
|
|
|
lw = cfs_rq->load;
|
2009-01-02 11:16:42 +00:00
|
|
|
|
|
|
|
update_load_add(&lw, se->load.weight);
|
|
|
|
load = &lw;
|
|
|
|
}
|
2013-11-18 17:27:06 +00:00
|
|
|
slice = __calc_delta(slice, se->load.weight, load);
|
2009-01-02 11:16:42 +00:00
|
|
|
}
|
|
|
|
return slice;
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2007-10-15 15:00:13 +00:00
|
|
|
/*
|
2013-03-11 10:03:20 +00:00
|
|
|
* We calculate the vruntime slice of a to-be-inserted task.
|
2007-10-15 15:00:13 +00:00
|
|
|
*
|
2008-10-17 17:27:04 +00:00
|
|
|
* vs = s/w
|
2007-10-15 15:00:13 +00:00
|
|
|
*/
|
2008-10-17 17:27:04 +00:00
|
|
|
static u64 sched_vslice(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
2007-10-15 15:00:10 +00:00
|
|
|
{
|
2008-10-17 17:27:04 +00:00
|
|
|
return calc_delta_fair(sched_slice(cfs_rq, se), se);
|
2008-06-27 11:41:11 +00:00
|
|
|
}
|
|
|
|
|
2018-06-28 15:45:04 +00:00
|
|
|
#include "pelt.h"
|
sched/fair: Update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times:
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/seconds ops/seconds diff
cgroup
root 59652(+/- 0.18%) 59876(+/- 0.24%) +0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%) +0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%) +0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec) diff
cgroup
root 4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%) 138ms not reachable 276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%) 13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Morten.Rasmussen@arm.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: patrick.bellasi@arm.com
Cc: pjt@google.com
Cc: pkondeti@codeaurora.org
Cc: quentin.perret@arm.com
Cc: rjw@rjwysocki.net
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Link: https://lkml.kernel.org/r/1548257214-13745-3-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-01-23 15:26:53 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2017-04-11 09:08:42 +00:00
|
|
|
|
2016-06-22 17:03:13 +00:00
|
|
|
static int select_idle_sibling(struct task_struct *p, int prev_cpu, int cpu);
|
2013-10-07 10:29:17 +00:00
|
|
|
static unsigned long task_h_load(struct task_struct *p);
|
2018-07-04 10:17:40 +00:00
|
|
|
static unsigned long capacity_of(int cpu);
|
2013-10-07 10:29:17 +00:00
|
|
|
|
2015-07-15 00:04:39 +00:00
|
|
|
/* Give new sched_entity start runnable values to heavy its load in infant time */
|
|
|
|
void init_entity_runnable_average(struct sched_entity *se)
|
2013-06-20 02:18:47 +00:00
|
|
|
{
|
2015-07-15 00:04:39 +00:00
|
|
|
struct sched_avg *sa = &se->avg;
|
2013-06-20 02:18:47 +00:00
|
|
|
|
sched/fair: Align PELT windows between cfs_rq and its se
The PELT _sum values are a saw-tooth function, dropping on the decay
edge and then growing back up again during the window.
When these window-edges are not aligned between cfs_rq and se, we can
have the situation where, for example, on dequeue, the se decays
first.
Its _sum values will be small(er), while the cfs_rq _sum values will
still be on their way up. Because of this, the subtraction:
cfs_rq->avg._sum -= se->avg._sum will result in a positive value. This
will then, once the cfs_rq reaches an edge, translate into its _avg
value jumping up.
This is especially visible with the runnable_load bits, since they get
added/subtracted a lot.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-12 12:16:30 +00:00
|
|
|
memset(sa, 0, sizeof(*sa));
|
|
|
|
|
2016-10-19 12:45:23 +00:00
|
|
|
/*
|
2018-12-03 09:05:56 +00:00
|
|
|
* Tasks are initialized with full load to be seen as heavy tasks until
|
2016-10-19 12:45:23 +00:00
|
|
|
* they get a chance to stabilize to their real load level.
|
2018-12-03 09:05:56 +00:00
|
|
|
* Group entities are initialized with zero load to reflect the fact that
|
2016-10-19 12:45:23 +00:00
|
|
|
* nothing has been attached to the task group yet.
|
|
|
|
*/
|
|
|
|
if (entity_is_task(se))
|
2017-05-06 13:59:54 +00:00
|
|
|
sa->runnable_load_avg = sa->load_avg = scale_load_down(se->load.weight);
|
|
|
|
|
sched/fair: Align PELT windows between cfs_rq and its se
The PELT _sum values are a saw-tooth function, dropping on the decay
edge and then growing back up again during the window.
When these window-edges are not aligned between cfs_rq and se, we can
have the situation where, for example, on dequeue, the se decays
first.
Its _sum values will be small(er), while the cfs_rq _sum values will
still be on their way up. Because of this, the subtraction:
cfs_rq->avg._sum -= se->avg._sum will result in a positive value. This
will then, once the cfs_rq reaches an edge, translate into its _avg
value jumping up.
This is especially visible with the runnable_load bits, since they get
added/subtracted a lot.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-12 12:16:30 +00:00
|
|
|
se->runnable_weight = se->load.weight;
|
|
|
|
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
/* when this task enqueue'ed, it will contribute to its cfs_rq's load_avg */
|
2013-06-20 02:18:47 +00:00
|
|
|
}
|
2015-07-15 00:04:42 +00:00
|
|
|
|
2016-11-08 09:53:42 +00:00
|
|
|
static void attach_entity_cfs_rq(struct sched_entity *se);
|
2016-06-16 11:29:28 +00:00
|
|
|
|
2016-03-29 20:30:56 +00:00
|
|
|
/*
|
|
|
|
* With new tasks being created, their initial util_avgs are extrapolated
|
|
|
|
* based on the cfs_rq's current util_avg:
|
|
|
|
*
|
|
|
|
* util_avg = cfs_rq->util_avg / (cfs_rq->load_avg + 1) * se.load.weight
|
|
|
|
*
|
|
|
|
* However, in many cases, the above util_avg does not give a desired
|
|
|
|
* value. Moreover, the sum of the util_avgs may be divergent, such
|
|
|
|
* as when the series is a harmonic series.
|
|
|
|
*
|
|
|
|
* To solve this problem, we also cap the util_avg of successive tasks to
|
|
|
|
* only 1/2 of the left utilization budget:
|
|
|
|
*
|
2018-06-12 11:22:15 +00:00
|
|
|
* util_avg_cap = (cpu_scale - cfs_rq->avg.util_avg) / 2^n
|
2016-03-29 20:30:56 +00:00
|
|
|
*
|
2018-06-12 11:22:15 +00:00
|
|
|
* where n denotes the nth task and cpu_scale the CPU capacity.
|
2016-03-29 20:30:56 +00:00
|
|
|
*
|
2018-06-12 11:22:15 +00:00
|
|
|
* For example, for a CPU with 1024 of capacity, a simplest series from
|
|
|
|
* the beginning would be like:
|
2016-03-29 20:30:56 +00:00
|
|
|
*
|
|
|
|
* task util_avg: 512, 256, 128, 64, 32, 16, 8, ...
|
|
|
|
* cfs_rq util_avg: 512, 768, 896, 960, 992, 1008, 1016, ...
|
|
|
|
*
|
|
|
|
* Finally, that extrapolated util_avg is clamped to the cap (util_avg_cap)
|
|
|
|
* if util_avg > util_avg_cap.
|
|
|
|
*/
|
2019-01-22 16:25:01 +00:00
|
|
|
void post_init_entity_util_avg(struct task_struct *p)
|
2016-03-29 20:30:56 +00:00
|
|
|
{
|
2019-01-22 16:25:01 +00:00
|
|
|
struct sched_entity *se = &p->se;
|
2016-03-29 20:30:56 +00:00
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
|
|
|
struct sched_avg *sa = &se->avg;
|
2019-06-17 15:00:17 +00:00
|
|
|
long cpu_scale = arch_scale_cpu_capacity(cpu_of(rq_of(cfs_rq)));
|
2018-06-12 11:22:15 +00:00
|
|
|
long cap = (long)(cpu_scale - cfs_rq->avg.util_avg) / 2;
|
2016-03-29 20:30:56 +00:00
|
|
|
|
|
|
|
if (cap > 0) {
|
|
|
|
if (cfs_rq->avg.util_avg != 0) {
|
|
|
|
sa->util_avg = cfs_rq->avg.util_avg * se->load.weight;
|
|
|
|
sa->util_avg /= (cfs_rq->avg.load_avg + 1);
|
|
|
|
|
|
|
|
if (sa->util_avg > cap)
|
|
|
|
sa->util_avg = cap;
|
|
|
|
} else {
|
|
|
|
sa->util_avg = cap;
|
|
|
|
}
|
|
|
|
}
|
2016-06-16 11:29:28 +00:00
|
|
|
|
2019-01-22 16:25:01 +00:00
|
|
|
if (p->sched_class != &fair_sched_class) {
|
|
|
|
/*
|
|
|
|
* For !fair tasks do:
|
|
|
|
*
|
|
|
|
update_cfs_rq_load_avg(now, cfs_rq);
|
2020-01-15 10:20:20 +00:00
|
|
|
attach_entity_load_avg(cfs_rq, se);
|
2019-01-22 16:25:01 +00:00
|
|
|
switched_from_fair(rq, p);
|
|
|
|
*
|
|
|
|
* such that the next switched_to_fair() has the
|
|
|
|
* expected state.
|
|
|
|
*/
|
|
|
|
se->avg.last_update_time = cfs_rq_clock_pelt(cfs_rq);
|
|
|
|
return;
|
2016-06-16 11:29:28 +00:00
|
|
|
}
|
|
|
|
|
2016-11-08 09:53:42 +00:00
|
|
|
attach_entity_cfs_rq(se);
|
2016-03-29 20:30:56 +00:00
|
|
|
}
|
|
|
|
|
2016-06-16 11:29:28 +00:00
|
|
|
#else /* !CONFIG_SMP */
|
2015-07-15 00:04:39 +00:00
|
|
|
void init_entity_runnable_average(struct sched_entity *se)
|
2013-06-20 02:18:47 +00:00
|
|
|
{
|
|
|
|
}
|
2019-01-22 16:25:01 +00:00
|
|
|
void post_init_entity_util_avg(struct task_struct *p)
|
2016-03-29 20:30:56 +00:00
|
|
|
{
|
|
|
|
}
|
2016-06-21 12:27:50 +00:00
|
|
|
static void update_tg_load_avg(struct cfs_rq *cfs_rq, int force)
|
|
|
|
{
|
|
|
|
}
|
2016-06-16 11:29:28 +00:00
|
|
|
#endif /* CONFIG_SMP */
|
2013-06-20 02:18:47 +00:00
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
2013-11-18 17:27:06 +00:00
|
|
|
* Update the current task's runtime statistics.
|
2007-07-09 16:51:58 +00:00
|
|
|
*/
|
2007-08-09 09:16:47 +00:00
|
|
|
static void update_curr(struct cfs_rq *cfs_rq)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2007-10-15 15:00:03 +00:00
|
|
|
struct sched_entity *curr = cfs_rq->curr;
|
2013-04-11 23:51:02 +00:00
|
|
|
u64 now = rq_clock_task(rq_of(cfs_rq));
|
2013-11-18 17:27:06 +00:00
|
|
|
u64 delta_exec;
|
2007-07-09 16:51:58 +00:00
|
|
|
|
|
|
|
if (unlikely(!curr))
|
|
|
|
return;
|
|
|
|
|
2013-11-18 17:27:06 +00:00
|
|
|
delta_exec = now - curr->exec_start;
|
|
|
|
if (unlikely((s64)delta_exec <= 0))
|
2008-12-16 07:45:31 +00:00
|
|
|
return;
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2007-10-15 15:00:03 +00:00
|
|
|
curr->exec_start = now;
|
2007-12-02 19:04:49 +00:00
|
|
|
|
2013-11-18 17:27:06 +00:00
|
|
|
schedstat_set(curr->statistics.exec_max,
|
|
|
|
max(delta_exec, curr->statistics.exec_max));
|
|
|
|
|
|
|
|
curr->sum_exec_runtime += delta_exec;
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_add(cfs_rq->exec_clock, delta_exec);
|
2013-11-18 17:27:06 +00:00
|
|
|
|
|
|
|
curr->vruntime += calc_delta_fair(delta_exec, curr);
|
|
|
|
update_min_vruntime(cfs_rq);
|
|
|
|
|
2007-12-02 19:04:49 +00:00
|
|
|
if (entity_is_task(curr)) {
|
|
|
|
struct task_struct *curtask = task_of(curr);
|
|
|
|
|
2009-09-13 16:15:54 +00:00
|
|
|
trace_sched_stat_runtime(curtask, delta_exec, curr->vruntime);
|
2017-09-25 15:12:04 +00:00
|
|
|
cgroup_account_cputime(curtask, delta_exec);
|
timers: fix itimer/many thread hang
Overview
This patch reworks the handling of POSIX CPU timers, including the
ITIMER_PROF, ITIMER_VIRT timers and rlimit handling. It was put together
with the help of Roland McGrath, the owner and original writer of this code.
The problem we ran into, and the reason for this rework, has to do with using
a profiling timer in a process with a large number of threads. It appears
that the performance of the old implementation of run_posix_cpu_timers() was
at least O(n*3) (where "n" is the number of threads in a process) or worse.
Everything is fine with an increasing number of threads until the time taken
for that routine to run becomes the same as or greater than the tick time, at
which point things degrade rather quickly.
This patch fixes bug 9906, "Weird hang with NPTL and SIGPROF."
Code Changes
This rework corrects the implementation of run_posix_cpu_timers() to make it
run in constant time for a particular machine. (Performance may vary between
one machine and another depending upon whether the kernel is built as single-
or multiprocessor and, in the latter case, depending upon the number of
running processors.) To do this, at each tick we now update fields in
signal_struct as well as task_struct. The run_posix_cpu_timers() function
uses those fields to make its decisions.
We define a new structure, "task_cputime," to contain user, system and
scheduler times and use these in appropriate places:
struct task_cputime {
cputime_t utime;
cputime_t stime;
unsigned long long sum_exec_runtime;
};
This is included in the structure "thread_group_cputime," which is a new
substructure of signal_struct and which varies for uniprocessor versus
multiprocessor kernels. For uniprocessor kernels, it uses "task_cputime" as
a simple substructure, while for multiprocessor kernels it is a pointer:
struct thread_group_cputime {
struct task_cputime totals;
};
struct thread_group_cputime {
struct task_cputime *totals;
};
We also add a new task_cputime substructure directly to signal_struct, to
cache the earliest expiration of process-wide timers, and task_cputime also
replaces the it_*_expires fields of task_struct (used for earliest expiration
of thread timers). The "thread_group_cputime" structure contains process-wide
timers that are updated via account_user_time() and friends. In the non-SMP
case the structure is a simple aggregator; unfortunately in the SMP case that
simplicity was not achievable due to cache-line contention between CPUs (in
one measured case performance was actually _worse_ on a 16-cpu system than
the same test on a 4-cpu system, due to this contention). For SMP, the
thread_group_cputime counters are maintained as a per-cpu structure allocated
using alloc_percpu(). The timer functions update only the timer field in
the structure corresponding to the running CPU, obtained using per_cpu_ptr().
We define a set of inline functions in sched.h that we use to maintain the
thread_group_cputime structure and hide the differences between UP and SMP
implementations from the rest of the kernel. The thread_group_cputime_init()
function initializes the thread_group_cputime structure for the given task.
The thread_group_cputime_alloc() is a no-op for UP; for SMP it calls the
out-of-line function thread_group_cputime_alloc_smp() to allocate and fill
in the per-cpu structures and fields. The thread_group_cputime_free()
function, also a no-op for UP, in SMP frees the per-cpu structures. The
thread_group_cputime_clone_thread() function (also a UP no-op) for SMP calls
thread_group_cputime_alloc() if the per-cpu structures haven't yet been
allocated. The thread_group_cputime() function fills the task_cputime
structure it is passed with the contents of the thread_group_cputime fields;
in UP it's that simple but in SMP it must also safely check that tsk->signal
is non-NULL (if it is it just uses the appropriate fields of task_struct) and,
if so, sums the per-cpu values for each online CPU. Finally, the three
functions account_group_user_time(), account_group_system_time() and
account_group_exec_runtime() are used by timer functions to update the
respective fields of the thread_group_cputime structure.
Non-SMP operation is trivial and will not be mentioned further.
The per-cpu structure is always allocated when a task creates its first new
thread, via a call to thread_group_cputime_clone_thread() from copy_signal().
It is freed at process exit via a call to thread_group_cputime_free() from
cleanup_signal().
All functions that formerly summed utime/stime/sum_sched_runtime values from
from all threads in the thread group now use thread_group_cputime() to
snapshot the values in the thread_group_cputime structure or the values in
the task structure itself if the per-cpu structure hasn't been allocated.
Finally, the code in kernel/posix-cpu-timers.c has changed quite a bit.
The run_posix_cpu_timers() function has been split into a fast path and a
slow path; the former safely checks whether there are any expired thread
timers and, if not, just returns, while the slow path does the heavy lifting.
With the dedicated thread group fields, timers are no longer "rebalanced" and
the process_timer_rebalance() function and related code has gone away. All
summing loops are gone and all code that used them now uses the
thread_group_cputime() inline. When process-wide timers are set, the new
task_cputime structure in signal_struct is used to cache the earliest
expiration; this is checked in the fast path.
Performance
The fix appears not to add significant overhead to existing operations. It
generally performs the same as the current code except in two cases, one in
which it performs slightly worse (Case 5 below) and one in which it performs
very significantly better (Case 2 below). Overall it's a wash except in those
two cases.
I've since done somewhat more involved testing on a dual-core Opteron system.
Case 1: With no itimer running, for a test with 100,000 threads, the fixed
kernel took 1428.5 seconds, 513 seconds more than the unfixed system,
all of which was spent in the system. There were twice as many
voluntary context switches with the fix as without it.
Case 2: With an itimer running at .01 second ticks and 4000 threads (the most
an unmodified kernel can handle), the fixed kernel ran the test in
eight percent of the time (5.8 seconds as opposed to 70 seconds) and
had better tick accuracy (.012 seconds per tick as opposed to .023
seconds per tick).
Case 3: A 4000-thread test with an initial timer tick of .01 second and an
interval of 10,000 seconds (i.e. a timer that ticks only once) had
very nearly the same performance in both cases: 6.3 seconds elapsed
for the fixed kernel versus 5.5 seconds for the unfixed kernel.
With fewer threads (eight in these tests), the Case 1 test ran in essentially
the same time on both the modified and unmodified kernels (5.2 seconds versus
5.8 seconds). The Case 2 test ran in about the same time as well, 5.9 seconds
versus 5.4 seconds but again with much better tick accuracy, .013 seconds per
tick versus .025 seconds per tick for the unmodified kernel.
Since the fix affected the rlimit code, I also tested soft and hard CPU limits.
Case 4: With a hard CPU limit of 20 seconds and eight threads (and an itimer
running), the modified kernel was very slightly favored in that while
it killed the process in 19.997 seconds of CPU time (5.002 seconds of
wall time), only .003 seconds of that was system time, the rest was
user time. The unmodified kernel killed the process in 20.001 seconds
of CPU (5.014 seconds of wall time) of which .016 seconds was system
time. Really, though, the results were too close to call. The results
were essentially the same with no itimer running.
Case 5: With a soft limit of 20 seconds and a hard limit of 2000 seconds
(where the hard limit would never be reached) and an itimer running,
the modified kernel exhibited worse tick accuracy than the unmodified
kernel: .050 seconds/tick versus .028 seconds/tick. Otherwise,
performance was almost indistinguishable. With no itimer running this
test exhibited virtually identical behavior and times in both cases.
In times past I did some limited performance testing. those results are below.
On a four-cpu Opteron system without this fix, a sixteen-thread test executed
in 3569.991 seconds, of which user was 3568.435s and system was 1.556s. On
the same system with the fix, user and elapsed time were about the same, but
system time dropped to 0.007 seconds. Performance with eight, four and one
thread were comparable. Interestingly, the timer ticks with the fix seemed
more accurate: The sixteen-thread test with the fix received 149543 ticks
for 0.024 seconds per tick, while the same test without the fix received 58720
for 0.061 seconds per tick. Both cases were configured for an interval of
0.01 seconds. Again, the other tests were comparable. Each thread in this
test computed the primes up to 25,000,000.
I also did a test with a large number of threads, 100,000 threads, which is
impossible without the fix. In this case each thread computed the primes only
up to 10,000 (to make the runtime manageable). System time dominated, at
1546.968 seconds out of a total 2176.906 seconds (giving a user time of
629.938s). It received 147651 ticks for 0.015 seconds per tick, still quite
accurate. There is obviously no comparable test without the fix.
Signed-off-by: Frank Mayhar <fmayhar@google.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-09-12 16:54:39 +00:00
|
|
|
account_group_exec_runtime(curtask, delta_exec);
|
2007-12-02 19:04:49 +00:00
|
|
|
}
|
2011-07-21 16:43:30 +00:00
|
|
|
|
|
|
|
account_cfs_rq_runtime(cfs_rq, delta_exec);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
sched/cputime: Fix clock_nanosleep()/clock_gettime() inconsistency
Commit d670ec13178d0 "posix-cpu-timers: Cure SMP wobbles" fixes one glibc
test case in cost of breaking another one. After that commit, calling
clock_nanosleep(TIMER_ABSTIME, X) and then clock_gettime(&Y) can result
of Y time being smaller than X time.
Reproducer/tester can be found further below, it can be compiled and ran by:
gcc -o tst-cpuclock2 tst-cpuclock2.c -pthread
while ./tst-cpuclock2 ; do : ; done
This reproducer, when running on a buggy kernel, will complain
about "clock_gettime difference too small".
Issue happens because on start in thread_group_cputimer() we initialize
sum_exec_runtime of cputimer with threads runtime not yet accounted and
then add the threads runtime to running cputimer again on scheduler
tick, making it's sum_exec_runtime bigger than actual threads runtime.
KOSAKI Motohiro posted a fix for this problem, but that patch was never
applied: https://lkml.org/lkml/2013/5/26/191 .
This patch takes different approach to cure the problem. It calls
update_curr() when cputimer starts, that assure we will have updated
stats of running threads and on the next schedule tick we will account
only the runtime that elapsed from cputimer start. That also assure we
have consistent state between cpu times of individual threads and cpu
time of the process consisted by those threads.
Full reproducer (tst-cpuclock2.c):
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
#include <stdio.h>
#include <time.h>
#include <pthread.h>
#include <stdint.h>
#include <inttypes.h>
/* Parameters for the Linux kernel ABI for CPU clocks. */
#define CPUCLOCK_SCHED 2
#define MAKE_PROCESS_CPUCLOCK(pid, clock) \
((~(clockid_t) (pid) << 3) | (clockid_t) (clock))
static pthread_barrier_t barrier;
/* Help advance the clock. */
static void *chew_cpu(void *arg)
{
pthread_barrier_wait(&barrier);
while (1) ;
return NULL;
}
/* Don't use the glibc wrapper. */
static int do_nanosleep(int flags, const struct timespec *req)
{
clockid_t clock_id = MAKE_PROCESS_CPUCLOCK(0, CPUCLOCK_SCHED);
return syscall(SYS_clock_nanosleep, clock_id, flags, req, NULL);
}
static int64_t tsdiff(const struct timespec *before, const struct timespec *after)
{
int64_t before_i = before->tv_sec * 1000000000ULL + before->tv_nsec;
int64_t after_i = after->tv_sec * 1000000000ULL + after->tv_nsec;
return after_i - before_i;
}
int main(void)
{
int result = 0;
pthread_t th;
pthread_barrier_init(&barrier, NULL, 2);
if (pthread_create(&th, NULL, chew_cpu, NULL) != 0) {
perror("pthread_create");
return 1;
}
pthread_barrier_wait(&barrier);
/* The test. */
struct timespec before, after, sleeptimeabs;
int64_t sleepdiff, diffabs;
const struct timespec sleeptime = {.tv_sec = 0,.tv_nsec = 100000000 };
/* The relative nanosleep. Not sure why this is needed, but its presence
seems to make it easier to reproduce the problem. */
if (do_nanosleep(0, &sleeptime) != 0) {
perror("clock_nanosleep");
return 1;
}
/* Get the current time. */
if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &before) < 0) {
perror("clock_gettime[2]");
return 1;
}
/* Compute the absolute sleep time based on the current time. */
uint64_t nsec = before.tv_nsec + sleeptime.tv_nsec;
sleeptimeabs.tv_sec = before.tv_sec + nsec / 1000000000;
sleeptimeabs.tv_nsec = nsec % 1000000000;
/* Sleep for the computed time. */
if (do_nanosleep(TIMER_ABSTIME, &sleeptimeabs) != 0) {
perror("absolute clock_nanosleep");
return 1;
}
/* Get the time after the sleep. */
if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &after) < 0) {
perror("clock_gettime[3]");
return 1;
}
/* The time after sleep should always be equal to or after the absolute sleep
time passed to clock_nanosleep. */
sleepdiff = tsdiff(&sleeptimeabs, &after);
if (sleepdiff < 0) {
printf("absolute clock_nanosleep woke too early: %" PRId64 "\n", sleepdiff);
result = 1;
printf("Before %llu.%09llu\n", before.tv_sec, before.tv_nsec);
printf("After %llu.%09llu\n", after.tv_sec, after.tv_nsec);
printf("Sleep %llu.%09llu\n", sleeptimeabs.tv_sec, sleeptimeabs.tv_nsec);
}
/* The difference between the timestamps taken before and after the
clock_nanosleep call should be equal to or more than the duration of the
sleep. */
diffabs = tsdiff(&before, &after);
if (diffabs < sleeptime.tv_nsec) {
printf("clock_gettime difference too small: %" PRId64 "\n", diffabs);
result = 1;
}
pthread_cancel(th);
return result;
}
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20141112155843.GA24803@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-11-12 15:58:44 +00:00
|
|
|
static void update_curr_fair(struct rq *rq)
|
|
|
|
{
|
|
|
|
update_curr(cfs_rq_of(&rq->curr->se));
|
|
|
|
}
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
static inline void
|
2007-08-09 09:16:47 +00:00
|
|
|
update_stats_wait_start(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2016-06-17 17:43:26 +00:00
|
|
|
u64 wait_start, prev_wait_start;
|
|
|
|
|
|
|
|
if (!schedstat_enabled())
|
|
|
|
return;
|
|
|
|
|
|
|
|
wait_start = rq_clock(rq_of(cfs_rq));
|
|
|
|
prev_wait_start = schedstat_val(se->statistics.wait_start);
|
2015-11-13 03:38:54 +00:00
|
|
|
|
|
|
|
if (entity_is_task(se) && task_on_rq_migrating(task_of(se)) &&
|
2016-06-17 17:43:26 +00:00
|
|
|
likely(wait_start > prev_wait_start))
|
|
|
|
wait_start -= prev_wait_start;
|
2015-11-13 03:38:54 +00:00
|
|
|
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_set(se->statistics.wait_start, wait_start);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2016-06-17 17:43:26 +00:00
|
|
|
static inline void
|
2015-11-13 03:38:54 +00:00
|
|
|
update_stats_wait_end(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
|
|
|
struct task_struct *p;
|
2016-02-05 09:08:36 +00:00
|
|
|
u64 delta;
|
|
|
|
|
2016-06-17 17:43:26 +00:00
|
|
|
if (!schedstat_enabled())
|
|
|
|
return;
|
|
|
|
|
|
|
|
delta = rq_clock(rq_of(cfs_rq)) - schedstat_val(se->statistics.wait_start);
|
2015-11-13 03:38:54 +00:00
|
|
|
|
|
|
|
if (entity_is_task(se)) {
|
|
|
|
p = task_of(se);
|
|
|
|
if (task_on_rq_migrating(p)) {
|
|
|
|
/*
|
|
|
|
* Preserve migrating task's wait time so wait_start
|
|
|
|
* time stamp can be adjusted to accumulate wait time
|
|
|
|
* prior to migration.
|
|
|
|
*/
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_set(se->statistics.wait_start, delta);
|
2015-11-13 03:38:54 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
trace_sched_stat_wait(p, delta);
|
|
|
|
}
|
|
|
|
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_set(se->statistics.wait_max,
|
2016-06-17 17:43:26 +00:00
|
|
|
max(schedstat_val(se->statistics.wait_max), delta));
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_inc(se->statistics.wait_count);
|
|
|
|
__schedstat_add(se->statistics.wait_sum, delta);
|
|
|
|
__schedstat_set(se->statistics.wait_start, 0);
|
2015-11-13 03:38:54 +00:00
|
|
|
}
|
|
|
|
|
2016-06-17 17:43:26 +00:00
|
|
|
static inline void
|
2016-06-17 17:43:23 +00:00
|
|
|
update_stats_enqueue_sleeper(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
|
|
|
struct task_struct *tsk = NULL;
|
2016-06-17 17:43:26 +00:00
|
|
|
u64 sleep_start, block_start;
|
|
|
|
|
|
|
|
if (!schedstat_enabled())
|
|
|
|
return;
|
|
|
|
|
|
|
|
sleep_start = schedstat_val(se->statistics.sleep_start);
|
|
|
|
block_start = schedstat_val(se->statistics.block_start);
|
2016-06-17 17:43:23 +00:00
|
|
|
|
|
|
|
if (entity_is_task(se))
|
|
|
|
tsk = task_of(se);
|
|
|
|
|
2016-06-17 17:43:26 +00:00
|
|
|
if (sleep_start) {
|
|
|
|
u64 delta = rq_clock(rq_of(cfs_rq)) - sleep_start;
|
2016-06-17 17:43:23 +00:00
|
|
|
|
|
|
|
if ((s64)delta < 0)
|
|
|
|
delta = 0;
|
|
|
|
|
2016-06-17 17:43:26 +00:00
|
|
|
if (unlikely(delta > schedstat_val(se->statistics.sleep_max)))
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_set(se->statistics.sleep_max, delta);
|
2016-06-17 17:43:23 +00:00
|
|
|
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_set(se->statistics.sleep_start, 0);
|
|
|
|
__schedstat_add(se->statistics.sum_sleep_runtime, delta);
|
2016-06-17 17:43:23 +00:00
|
|
|
|
|
|
|
if (tsk) {
|
|
|
|
account_scheduler_latency(tsk, delta >> 10, 1);
|
|
|
|
trace_sched_stat_sleep(tsk, delta);
|
|
|
|
}
|
|
|
|
}
|
2016-06-17 17:43:26 +00:00
|
|
|
if (block_start) {
|
|
|
|
u64 delta = rq_clock(rq_of(cfs_rq)) - block_start;
|
2016-06-17 17:43:23 +00:00
|
|
|
|
|
|
|
if ((s64)delta < 0)
|
|
|
|
delta = 0;
|
|
|
|
|
2016-06-17 17:43:26 +00:00
|
|
|
if (unlikely(delta > schedstat_val(se->statistics.block_max)))
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_set(se->statistics.block_max, delta);
|
2016-06-17 17:43:23 +00:00
|
|
|
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_set(se->statistics.block_start, 0);
|
|
|
|
__schedstat_add(se->statistics.sum_sleep_runtime, delta);
|
2016-06-17 17:43:23 +00:00
|
|
|
|
|
|
|
if (tsk) {
|
|
|
|
if (tsk->in_iowait) {
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_add(se->statistics.iowait_sum, delta);
|
|
|
|
__schedstat_inc(se->statistics.iowait_count);
|
2016-06-17 17:43:23 +00:00
|
|
|
trace_sched_stat_iowait(tsk, delta);
|
|
|
|
}
|
|
|
|
|
|
|
|
trace_sched_stat_blocked(tsk, delta);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Blocking time is in units of nanosecs, so shift by
|
|
|
|
* 20 to get a milliseconds-range estimation of the
|
|
|
|
* amount of time that the task spent sleeping:
|
|
|
|
*/
|
|
|
|
if (unlikely(prof_on == SLEEP_PROFILING)) {
|
|
|
|
profile_hits(SLEEP_PROFILING,
|
|
|
|
(void *)get_wchan(tsk),
|
|
|
|
delta >> 20);
|
|
|
|
}
|
|
|
|
account_scheduler_latency(tsk, delta >> 10, 0);
|
|
|
|
}
|
|
|
|
}
|
2015-11-13 03:38:54 +00:00
|
|
|
}
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* Task is being enqueued - update stats:
|
|
|
|
*/
|
2016-02-05 09:08:36 +00:00
|
|
|
static inline void
|
2016-06-17 17:43:23 +00:00
|
|
|
update_stats_enqueue(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2016-06-17 17:43:26 +00:00
|
|
|
if (!schedstat_enabled())
|
|
|
|
return;
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* Are we enqueueing a waiting task? (for current tasks
|
|
|
|
* a dequeue/enqueue event is a NOP)
|
|
|
|
*/
|
2007-10-15 15:00:03 +00:00
|
|
|
if (se != cfs_rq->curr)
|
2007-08-09 09:16:47 +00:00
|
|
|
update_stats_wait_start(cfs_rq, se);
|
2016-06-17 17:43:23 +00:00
|
|
|
|
|
|
|
if (flags & ENQUEUE_WAKEUP)
|
|
|
|
update_stats_enqueue_sleeper(cfs_rq, se);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
2016-02-05 09:08:36 +00:00
|
|
|
update_stats_dequeue(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2016-06-17 17:43:26 +00:00
|
|
|
|
|
|
|
if (!schedstat_enabled())
|
|
|
|
return;
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* Mark the end of the wait period if dequeueing a
|
|
|
|
* waiting task:
|
|
|
|
*/
|
2007-10-15 15:00:03 +00:00
|
|
|
if (se != cfs_rq->curr)
|
2007-08-09 09:16:47 +00:00
|
|
|
update_stats_wait_end(cfs_rq, se);
|
2016-02-05 09:08:36 +00:00
|
|
|
|
2016-06-17 17:43:26 +00:00
|
|
|
if ((flags & DEQUEUE_SLEEP) && entity_is_task(se)) {
|
|
|
|
struct task_struct *tsk = task_of(se);
|
2016-02-05 09:08:36 +00:00
|
|
|
|
2016-06-17 17:43:26 +00:00
|
|
|
if (tsk->state & TASK_INTERRUPTIBLE)
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_set(se->statistics.sleep_start,
|
2016-06-17 17:43:26 +00:00
|
|
|
rq_clock(rq_of(cfs_rq)));
|
|
|
|
if (tsk->state & TASK_UNINTERRUPTIBLE)
|
2018-01-23 19:34:30 +00:00
|
|
|
__schedstat_set(se->statistics.block_start,
|
2016-06-17 17:43:26 +00:00
|
|
|
rq_clock(rq_of(cfs_rq)));
|
2016-02-05 09:08:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* We are picking a new current task - update its stats:
|
|
|
|
*/
|
|
|
|
static inline void
|
2007-08-09 09:16:47 +00:00
|
|
|
update_stats_curr_start(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We are starting a new run period:
|
|
|
|
*/
|
2013-04-11 23:51:02 +00:00
|
|
|
se->exec_start = rq_clock_task(rq_of(cfs_rq));
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**************************************************
|
|
|
|
* Scheduling class queueing methods:
|
|
|
|
*/
|
|
|
|
|
2012-10-25 12:16:43 +00:00
|
|
|
#ifdef CONFIG_NUMA_BALANCING
|
|
|
|
/*
|
2013-10-07 10:28:55 +00:00
|
|
|
* Approximate time to scan a full NUMA task in ms. The task scan period is
|
|
|
|
* calculated based on the tasks virtual memory size and
|
|
|
|
* numa_balancing_scan_size.
|
2012-10-25 12:16:43 +00:00
|
|
|
*/
|
2013-10-07 10:28:55 +00:00
|
|
|
unsigned int sysctl_numa_balancing_scan_period_min = 1000;
|
|
|
|
unsigned int sysctl_numa_balancing_scan_period_max = 60000;
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
|
|
|
|
/* Portion of address space to scan in MB */
|
|
|
|
unsigned int sysctl_numa_balancing_scan_size = 256;
|
2012-10-25 12:16:43 +00:00
|
|
|
|
2012-10-25 12:16:47 +00:00
|
|
|
/* Scan @scan_size MB every @scan_period after an initial @scan_delay in ms */
|
|
|
|
unsigned int sysctl_numa_balancing_scan_delay = 1000;
|
|
|
|
|
2017-07-31 19:28:47 +00:00
|
|
|
struct numa_group {
|
2019-01-18 12:27:28 +00:00
|
|
|
refcount_t refcount;
|
2017-07-31 19:28:47 +00:00
|
|
|
|
|
|
|
spinlock_t lock; /* nr_tasks, tasks */
|
|
|
|
int nr_tasks;
|
|
|
|
pid_t gid;
|
|
|
|
int active_nodes;
|
|
|
|
|
|
|
|
struct rcu_head rcu;
|
|
|
|
unsigned long total_faults;
|
|
|
|
unsigned long max_faults_cpu;
|
|
|
|
/*
|
|
|
|
* Faults_cpu is used to decide whether memory should move
|
|
|
|
* towards the CPU. As a consequence, these stats are weighted
|
|
|
|
* more by CPU use than by memory faults.
|
|
|
|
*/
|
|
|
|
unsigned long *faults_cpu;
|
|
|
|
unsigned long faults[0];
|
|
|
|
};
|
|
|
|
|
2019-07-16 15:20:47 +00:00
|
|
|
/*
|
|
|
|
* For functions that can be called in multiple contexts that permit reading
|
|
|
|
* ->numa_group (see struct task_struct for locking rules).
|
|
|
|
*/
|
|
|
|
static struct numa_group *deref_task_numa_group(struct task_struct *p)
|
|
|
|
{
|
|
|
|
return rcu_dereference_check(p->numa_group, p == current ||
|
|
|
|
(lockdep_is_held(&task_rq(p)->lock) && !READ_ONCE(p->on_cpu)));
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct numa_group *deref_curr_numa_group(struct task_struct *p)
|
|
|
|
{
|
|
|
|
return rcu_dereference_protected(p->numa_group, p == current);
|
|
|
|
}
|
|
|
|
|
2017-07-31 19:28:47 +00:00
|
|
|
static inline unsigned long group_faults_priv(struct numa_group *ng);
|
|
|
|
static inline unsigned long group_faults_shared(struct numa_group *ng);
|
|
|
|
|
2013-10-07 10:28:55 +00:00
|
|
|
static unsigned int task_nr_scan_windows(struct task_struct *p)
|
|
|
|
{
|
|
|
|
unsigned long rss = 0;
|
|
|
|
unsigned long nr_scan_pages;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculations based on RSS as non-present and empty pages are skipped
|
|
|
|
* by the PTE scanner and NUMA hinting faults should be trapped based
|
|
|
|
* on resident pages
|
|
|
|
*/
|
|
|
|
nr_scan_pages = sysctl_numa_balancing_scan_size << (20 - PAGE_SHIFT);
|
|
|
|
rss = get_mm_rss(p->mm);
|
|
|
|
if (!rss)
|
|
|
|
rss = nr_scan_pages;
|
|
|
|
|
|
|
|
rss = round_up(rss, nr_scan_pages);
|
|
|
|
return rss / nr_scan_pages;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* For sanitys sake, never scan more PTEs than MAX_SCAN_WINDOW MB/sec. */
|
|
|
|
#define MAX_SCAN_WINDOW 2560
|
|
|
|
|
|
|
|
static unsigned int task_scan_min(struct task_struct *p)
|
|
|
|
{
|
2015-04-28 20:00:20 +00:00
|
|
|
unsigned int scan_size = READ_ONCE(sysctl_numa_balancing_scan_size);
|
2013-10-07 10:28:55 +00:00
|
|
|
unsigned int scan, floor;
|
|
|
|
unsigned int windows = 1;
|
|
|
|
|
2014-10-16 10:39:37 +00:00
|
|
|
if (scan_size < MAX_SCAN_WINDOW)
|
|
|
|
windows = MAX_SCAN_WINDOW / scan_size;
|
2013-10-07 10:28:55 +00:00
|
|
|
floor = 1000 / windows;
|
|
|
|
|
|
|
|
scan = sysctl_numa_balancing_scan_period_min / task_nr_scan_windows(p);
|
|
|
|
return max_t(unsigned int, floor, scan);
|
|
|
|
}
|
|
|
|
|
2017-07-31 19:28:47 +00:00
|
|
|
static unsigned int task_scan_start(struct task_struct *p)
|
|
|
|
{
|
|
|
|
unsigned long smin = task_scan_min(p);
|
|
|
|
unsigned long period = smin;
|
2019-07-16 15:20:47 +00:00
|
|
|
struct numa_group *ng;
|
2017-07-31 19:28:47 +00:00
|
|
|
|
|
|
|
/* Scale the maximum scan period with the amount of shared memory. */
|
2019-07-16 15:20:47 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
ng = rcu_dereference(p->numa_group);
|
|
|
|
if (ng) {
|
2017-07-31 19:28:47 +00:00
|
|
|
unsigned long shared = group_faults_shared(ng);
|
|
|
|
unsigned long private = group_faults_priv(ng);
|
|
|
|
|
2019-01-18 12:27:28 +00:00
|
|
|
period *= refcount_read(&ng->refcount);
|
2017-07-31 19:28:47 +00:00
|
|
|
period *= shared + 1;
|
|
|
|
period /= private + shared + 1;
|
|
|
|
}
|
2019-07-16 15:20:47 +00:00
|
|
|
rcu_read_unlock();
|
2017-07-31 19:28:47 +00:00
|
|
|
|
|
|
|
return max(smin, period);
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:28:55 +00:00
|
|
|
static unsigned int task_scan_max(struct task_struct *p)
|
|
|
|
{
|
2017-07-31 19:28:47 +00:00
|
|
|
unsigned long smin = task_scan_min(p);
|
|
|
|
unsigned long smax;
|
2019-07-16 15:20:47 +00:00
|
|
|
struct numa_group *ng;
|
2013-10-07 10:28:55 +00:00
|
|
|
|
|
|
|
/* Watch for min being lower than max due to floor calculations */
|
|
|
|
smax = sysctl_numa_balancing_scan_period_max / task_nr_scan_windows(p);
|
2017-07-31 19:28:47 +00:00
|
|
|
|
|
|
|
/* Scale the maximum scan period with the amount of shared memory. */
|
2019-07-16 15:20:47 +00:00
|
|
|
ng = deref_curr_numa_group(p);
|
|
|
|
if (ng) {
|
2017-07-31 19:28:47 +00:00
|
|
|
unsigned long shared = group_faults_shared(ng);
|
|
|
|
unsigned long private = group_faults_priv(ng);
|
|
|
|
unsigned long period = smax;
|
|
|
|
|
2019-01-18 12:27:28 +00:00
|
|
|
period *= refcount_read(&ng->refcount);
|
2017-07-31 19:28:47 +00:00
|
|
|
period *= shared + 1;
|
|
|
|
period /= private + shared + 1;
|
|
|
|
|
|
|
|
smax = max(smax, period);
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:28:55 +00:00
|
|
|
return max(smin, smax);
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:33 +00:00
|
|
|
static void account_numa_enqueue(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
2019-03-05 23:42:58 +00:00
|
|
|
rq->nr_numa_running += (p->numa_preferred_nid != NUMA_NO_NODE);
|
2013-10-07 10:29:33 +00:00
|
|
|
rq->nr_preferred_running += (p->numa_preferred_nid == task_node(p));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void account_numa_dequeue(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
2019-03-05 23:42:58 +00:00
|
|
|
rq->nr_numa_running -= (p->numa_preferred_nid != NUMA_NO_NODE);
|
2013-10-07 10:29:33 +00:00
|
|
|
rq->nr_preferred_running -= (p->numa_preferred_nid == task_node(p));
|
|
|
|
}
|
|
|
|
|
2014-01-27 22:03:48 +00:00
|
|
|
/* Shared or private faults. */
|
|
|
|
#define NR_NUMA_HINT_FAULT_TYPES 2
|
|
|
|
|
|
|
|
/* Memory and CPU locality */
|
|
|
|
#define NR_NUMA_HINT_FAULT_STATS (NR_NUMA_HINT_FAULT_TYPES * 2)
|
|
|
|
|
|
|
|
/* Averaged statistics, and temporary buffers. */
|
|
|
|
#define NR_NUMA_HINT_FAULT_BUCKETS (NR_NUMA_HINT_FAULT_STATS * 2)
|
|
|
|
|
2013-10-07 10:29:22 +00:00
|
|
|
pid_t task_numa_group_id(struct task_struct *p)
|
|
|
|
{
|
2019-07-16 15:20:47 +00:00
|
|
|
struct numa_group *ng;
|
|
|
|
pid_t gid = 0;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
ng = rcu_dereference(p->numa_group);
|
|
|
|
if (ng)
|
|
|
|
gid = ng->gid;
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return gid;
|
2013-10-07 10:29:22 +00:00
|
|
|
}
|
|
|
|
|
2014-10-31 00:13:31 +00:00
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* The averaged statistics, shared & private, memory & CPU,
|
2014-10-31 00:13:31 +00:00
|
|
|
* occupy the first half of the array. The second half of the
|
|
|
|
* array is for current counters, which are averaged into the
|
|
|
|
* first set by task_numa_placement.
|
|
|
|
*/
|
|
|
|
static inline int task_faults_idx(enum numa_faults_stats s, int nid, int priv)
|
2013-10-07 10:29:03 +00:00
|
|
|
{
|
2014-10-31 00:13:31 +00:00
|
|
|
return NR_NUMA_HINT_FAULT_TYPES * (s * nr_node_ids + nid) + priv;
|
2013-10-07 10:29:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned long task_faults(struct task_struct *p, int nid)
|
|
|
|
{
|
2014-10-31 00:13:31 +00:00
|
|
|
if (!p->numa_faults)
|
2013-10-07 10:29:03 +00:00
|
|
|
return 0;
|
|
|
|
|
2014-10-31 00:13:31 +00:00
|
|
|
return p->numa_faults[task_faults_idx(NUMA_MEM, nid, 0)] +
|
|
|
|
p->numa_faults[task_faults_idx(NUMA_MEM, nid, 1)];
|
2013-10-07 10:29:03 +00:00
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:27 +00:00
|
|
|
static inline unsigned long group_faults(struct task_struct *p, int nid)
|
|
|
|
{
|
2019-07-16 15:20:47 +00:00
|
|
|
struct numa_group *ng = deref_task_numa_group(p);
|
|
|
|
|
|
|
|
if (!ng)
|
2013-10-07 10:29:27 +00:00
|
|
|
return 0;
|
|
|
|
|
2019-07-16 15:20:47 +00:00
|
|
|
return ng->faults[task_faults_idx(NUMA_MEM, nid, 0)] +
|
|
|
|
ng->faults[task_faults_idx(NUMA_MEM, nid, 1)];
|
2013-10-07 10:29:27 +00:00
|
|
|
}
|
|
|
|
|
2014-01-27 22:03:43 +00:00
|
|
|
static inline unsigned long group_faults_cpu(struct numa_group *group, int nid)
|
|
|
|
{
|
2014-10-31 00:13:31 +00:00
|
|
|
return group->faults_cpu[task_faults_idx(NUMA_MEM, nid, 0)] +
|
|
|
|
group->faults_cpu[task_faults_idx(NUMA_MEM, nid, 1)];
|
2014-01-27 22:03:43 +00:00
|
|
|
}
|
|
|
|
|
2017-07-31 19:28:47 +00:00
|
|
|
static inline unsigned long group_faults_priv(struct numa_group *ng)
|
|
|
|
{
|
|
|
|
unsigned long faults = 0;
|
|
|
|
int node;
|
|
|
|
|
|
|
|
for_each_online_node(node) {
|
|
|
|
faults += ng->faults[task_faults_idx(NUMA_MEM, node, 1)];
|
|
|
|
}
|
|
|
|
|
|
|
|
return faults;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned long group_faults_shared(struct numa_group *ng)
|
|
|
|
{
|
|
|
|
unsigned long faults = 0;
|
|
|
|
int node;
|
|
|
|
|
|
|
|
for_each_online_node(node) {
|
|
|
|
faults += ng->faults[task_faults_idx(NUMA_MEM, node, 0)];
|
|
|
|
}
|
|
|
|
|
|
|
|
return faults;
|
|
|
|
}
|
|
|
|
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
/*
|
|
|
|
* A node triggering more than 1/3 as many NUMA faults as the maximum is
|
|
|
|
* considered part of a numa group's pseudo-interleaving set. Migrations
|
|
|
|
* between these nodes are slowed down, to allow things to settle down.
|
|
|
|
*/
|
|
|
|
#define ACTIVE_NODE_FRACTION 3
|
|
|
|
|
|
|
|
static bool numa_is_active_node(int nid, struct numa_group *ng)
|
|
|
|
{
|
|
|
|
return group_faults_cpu(ng, nid) * ACTIVE_NODE_FRACTION > ng->max_faults_cpu;
|
|
|
|
}
|
|
|
|
|
2014-10-17 07:29:52 +00:00
|
|
|
/* Handle placement on systems where not all nodes are directly connected. */
|
|
|
|
static unsigned long score_nearby_nodes(struct task_struct *p, int nid,
|
|
|
|
int maxdist, bool task)
|
|
|
|
{
|
|
|
|
unsigned long score = 0;
|
|
|
|
int node;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* All nodes are directly connected, and the same distance
|
|
|
|
* from each other. No need for fancy placement algorithms.
|
|
|
|
*/
|
|
|
|
if (sched_numa_topology_type == NUMA_DIRECT)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This code is called for each node, introducing N^2 complexity,
|
|
|
|
* which should be ok given the number of nodes rarely exceeds 8.
|
|
|
|
*/
|
|
|
|
for_each_online_node(node) {
|
|
|
|
unsigned long faults;
|
|
|
|
int dist = node_distance(nid, node);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The furthest away nodes in the system are not interesting
|
|
|
|
* for placement; nid was already counted.
|
|
|
|
*/
|
|
|
|
if (dist == sched_max_numa_distance || node == nid)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* On systems with a backplane NUMA topology, compare groups
|
|
|
|
* of nodes, and move tasks towards the group with the most
|
|
|
|
* memory accesses. When comparing two nodes at distance
|
|
|
|
* "hoplimit", only nodes closer by than "hoplimit" are part
|
|
|
|
* of each group. Skip other nodes.
|
|
|
|
*/
|
|
|
|
if (sched_numa_topology_type == NUMA_BACKPLANE &&
|
2018-06-20 17:02:48 +00:00
|
|
|
dist >= maxdist)
|
2014-10-17 07:29:52 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Add up the faults from nearby nodes. */
|
|
|
|
if (task)
|
|
|
|
faults = task_faults(p, node);
|
|
|
|
else
|
|
|
|
faults = group_faults(p, node);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* On systems with a glueless mesh NUMA topology, there are
|
|
|
|
* no fixed "groups of nodes". Instead, nodes that are not
|
|
|
|
* directly connected bounce traffic through intermediate
|
|
|
|
* nodes; a numa_group can occupy any set of nodes.
|
|
|
|
* The further away a node is, the less the faults count.
|
|
|
|
* This seems to result in good task placement.
|
|
|
|
*/
|
|
|
|
if (sched_numa_topology_type == NUMA_GLUELESS_MESH) {
|
|
|
|
faults *= (sched_max_numa_distance - dist);
|
|
|
|
faults /= (sched_max_numa_distance - LOCAL_DISTANCE);
|
|
|
|
}
|
|
|
|
|
|
|
|
score += faults;
|
|
|
|
}
|
|
|
|
|
|
|
|
return score;
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:27 +00:00
|
|
|
/*
|
|
|
|
* These return the fraction of accesses done by a particular task, or
|
|
|
|
* task group, on a particular numa node. The group weight is given a
|
|
|
|
* larger multiplier, in order to group tasks together that are almost
|
|
|
|
* evenly spread out between numa nodes.
|
|
|
|
*/
|
2014-10-17 07:29:51 +00:00
|
|
|
static inline unsigned long task_weight(struct task_struct *p, int nid,
|
|
|
|
int dist)
|
2013-10-07 10:29:27 +00:00
|
|
|
{
|
2014-10-17 07:29:51 +00:00
|
|
|
unsigned long faults, total_faults;
|
2013-10-07 10:29:27 +00:00
|
|
|
|
2014-10-31 00:13:31 +00:00
|
|
|
if (!p->numa_faults)
|
2013-10-07 10:29:27 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
total_faults = p->total_numa_faults;
|
|
|
|
|
|
|
|
if (!total_faults)
|
|
|
|
return 0;
|
|
|
|
|
2014-10-17 07:29:51 +00:00
|
|
|
faults = task_faults(p, nid);
|
2014-10-17 07:29:52 +00:00
|
|
|
faults += score_nearby_nodes(p, nid, dist, true);
|
|
|
|
|
2014-10-17 07:29:51 +00:00
|
|
|
return 1000 * faults / total_faults;
|
2013-10-07 10:29:27 +00:00
|
|
|
}
|
|
|
|
|
2014-10-17 07:29:51 +00:00
|
|
|
static inline unsigned long group_weight(struct task_struct *p, int nid,
|
|
|
|
int dist)
|
2013-10-07 10:29:27 +00:00
|
|
|
{
|
2019-07-16 15:20:47 +00:00
|
|
|
struct numa_group *ng = deref_task_numa_group(p);
|
2014-10-17 07:29:51 +00:00
|
|
|
unsigned long faults, total_faults;
|
|
|
|
|
2019-07-16 15:20:47 +00:00
|
|
|
if (!ng)
|
2014-10-17 07:29:51 +00:00
|
|
|
return 0;
|
|
|
|
|
2019-07-16 15:20:47 +00:00
|
|
|
total_faults = ng->total_faults;
|
2014-10-17 07:29:51 +00:00
|
|
|
|
|
|
|
if (!total_faults)
|
2013-10-07 10:29:27 +00:00
|
|
|
return 0;
|
|
|
|
|
2014-10-17 07:29:51 +00:00
|
|
|
faults = group_faults(p, nid);
|
2014-10-17 07:29:52 +00:00
|
|
|
faults += score_nearby_nodes(p, nid, dist, false);
|
|
|
|
|
2014-10-17 07:29:51 +00:00
|
|
|
return 1000 * faults / total_faults;
|
2013-10-07 10:29:27 +00:00
|
|
|
}
|
|
|
|
|
2014-01-27 22:03:44 +00:00
|
|
|
bool should_numa_migrate_memory(struct task_struct *p, struct page * page,
|
|
|
|
int src_nid, int dst_cpu)
|
|
|
|
{
|
2019-07-16 15:20:47 +00:00
|
|
|
struct numa_group *ng = deref_curr_numa_group(p);
|
2014-01-27 22:03:44 +00:00
|
|
|
int dst_nid = cpu_to_node(dst_cpu);
|
|
|
|
int last_cpupid, this_cpupid;
|
|
|
|
|
|
|
|
this_cpupid = cpu_pid_to_cpupid(dst_cpu, current->pid);
|
2018-10-01 10:05:25 +00:00
|
|
|
last_cpupid = page_cpupid_xchg_last(page, this_cpupid);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allow first faults or private faults to migrate immediately early in
|
|
|
|
* the lifetime of a task. The magic number 4 is based on waiting for
|
|
|
|
* two full passes of the "multi-stage node selection" test that is
|
|
|
|
* executed below.
|
|
|
|
*/
|
2019-03-05 23:42:58 +00:00
|
|
|
if ((p->numa_preferred_nid == NUMA_NO_NODE || p->numa_scan_seq <= 4) &&
|
2018-10-01 10:05:25 +00:00
|
|
|
(cpupid_pid_unset(last_cpupid) || cpupid_match_pid(p, last_cpupid)))
|
|
|
|
return true;
|
2014-01-27 22:03:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Multi-stage node selection is used in conjunction with a periodic
|
|
|
|
* migration fault to build a temporal task<->page relation. By using
|
|
|
|
* a two-stage filter we remove short/unlikely relations.
|
|
|
|
*
|
|
|
|
* Using P(p) ~ n_p / n_t as per frequentist probability, we can equate
|
|
|
|
* a task's usage of a particular page (n_p) per total usage of this
|
|
|
|
* page (n_t) (in a given time-span) to a probability.
|
|
|
|
*
|
|
|
|
* Our periodic faults will sample this probability and getting the
|
|
|
|
* same result twice in a row, given these samples are fully
|
|
|
|
* independent, is then given by P(n)^2, provided our sample period
|
|
|
|
* is sufficiently short compared to the usage pattern.
|
|
|
|
*
|
|
|
|
* This quadric squishes small probabilities, making it less likely we
|
|
|
|
* act on an unlikely task<->page relation.
|
|
|
|
*/
|
|
|
|
if (!cpupid_pid_unset(last_cpupid) &&
|
|
|
|
cpupid_to_nid(last_cpupid) != dst_nid)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Always allow migrate on private faults */
|
|
|
|
if (cpupid_match_pid(p, last_cpupid))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/* A shared fault, but p->numa_group has not been set up yet. */
|
|
|
|
if (!ng)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
* Destination node is much more heavily used than the source
|
|
|
|
* node? Allow migration.
|
2014-01-27 22:03:44 +00:00
|
|
|
*/
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
if (group_faults_cpu(ng, dst_nid) > group_faults_cpu(ng, src_nid) *
|
|
|
|
ACTIVE_NODE_FRACTION)
|
2014-01-27 22:03:44 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
* Distribute memory according to CPU & memory use on each node,
|
|
|
|
* with 3/4 hysteresis to avoid unnecessary memory migrations:
|
|
|
|
*
|
|
|
|
* faults_cpu(dst) 3 faults_cpu(src)
|
|
|
|
* --------------- * - > ---------------
|
|
|
|
* faults_mem(dst) 4 faults_mem(src)
|
2014-01-27 22:03:44 +00:00
|
|
|
*/
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
return group_faults_cpu(ng, dst_nid) * group_faults(p, src_nid) * 3 >
|
|
|
|
group_faults_cpu(ng, src_nid) * group_faults(p, dst_nid) * 4;
|
2014-01-27 22:03:44 +00:00
|
|
|
}
|
|
|
|
|
2019-10-18 13:26:36 +00:00
|
|
|
static inline unsigned long cfs_rq_runnable_load_avg(struct cfs_rq *cfs_rq);
|
|
|
|
|
|
|
|
static unsigned long cpu_runnable_load(struct rq *rq)
|
|
|
|
{
|
|
|
|
return cfs_rq_runnable_load_avg(&rq->cfs);
|
|
|
|
}
|
2013-10-07 10:29:10 +00:00
|
|
|
|
2013-10-07 10:29:17 +00:00
|
|
|
/* Cached statistics for all CPUs within a node */
|
2013-10-07 10:29:10 +00:00
|
|
|
struct numa_stats {
|
|
|
|
unsigned long load;
|
2013-10-07 10:29:17 +00:00
|
|
|
|
|
|
|
/* Total compute capacity of CPUs on a node */
|
2014-05-26 22:19:34 +00:00
|
|
|
unsigned long compute_capacity;
|
2013-10-07 10:29:10 +00:00
|
|
|
};
|
2013-10-07 10:29:02 +00:00
|
|
|
|
2013-10-07 10:29:17 +00:00
|
|
|
/*
|
|
|
|
* XXX borrowed from update_sg_lb_stats
|
|
|
|
*/
|
|
|
|
static void update_numa_stats(struct numa_stats *ns, int nid)
|
|
|
|
{
|
2018-08-29 13:19:09 +00:00
|
|
|
int cpu;
|
2013-10-07 10:29:17 +00:00
|
|
|
|
|
|
|
memset(ns, 0, sizeof(*ns));
|
|
|
|
for_each_cpu(cpu, cpumask_of_node(nid)) {
|
|
|
|
struct rq *rq = cpu_rq(cpu);
|
|
|
|
|
2019-06-18 12:23:10 +00:00
|
|
|
ns->load += cpu_runnable_load(rq);
|
2014-05-26 22:19:38 +00:00
|
|
|
ns->compute_capacity += capacity_of(cpu);
|
2013-10-07 10:29:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:10 +00:00
|
|
|
struct task_numa_env {
|
|
|
|
struct task_struct *p;
|
2013-10-07 10:29:02 +00:00
|
|
|
|
2013-10-07 10:29:10 +00:00
|
|
|
int src_cpu, src_nid;
|
|
|
|
int dst_cpu, dst_nid;
|
2013-10-07 10:29:02 +00:00
|
|
|
|
2013-10-07 10:29:10 +00:00
|
|
|
struct numa_stats src_stats, dst_stats;
|
2013-10-07 10:29:02 +00:00
|
|
|
|
2013-12-05 11:10:17 +00:00
|
|
|
int imbalance_pct;
|
2014-10-17 07:29:51 +00:00
|
|
|
int dist;
|
2013-10-07 10:29:17 +00:00
|
|
|
|
|
|
|
struct task_struct *best_task;
|
|
|
|
long best_imp;
|
2013-10-07 10:29:10 +00:00
|
|
|
int best_cpu;
|
|
|
|
};
|
|
|
|
|
2013-10-07 10:29:17 +00:00
|
|
|
static void task_numa_assign(struct task_numa_env *env,
|
|
|
|
struct task_struct *p, long imp)
|
|
|
|
{
|
sched/numa: Stop multiple tasks from moving to the CPU at the same time
Task migration under NUMA balancing can happen in parallel. More than
one task might choose to migrate to the same CPU at the same time. This
can result in:
- During task swap, choosing a task that was not part of the evaluation.
- During task swap, task which just got moved into its preferred node,
moving to a completely different node.
- During task swap, task failing to move to the preferred node, will have
to wait an extra interval for the next migrate opportunity.
- During task movement, multiple task movements can cause load imbalance.
This problem is more likely if there are more cores per node or more
nodes in the system.
Use a per run-queue variable to check if NUMA-balance is active on the
run-queue.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200194 203353 1.57797
1 311331 328205 5.41995
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 197654 214384 8.46429
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 192605 188553 -2.10379
1 213402 196273 -8.02664
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 52227.1 57581.2 10.2516
1 102529 103468 0.915838
There is a regression on power 9 box. If we look at the details,
that box has a sudden jump in cache-misses with this patch.
All other parameters seem to be pointing towards NUMA
consolidation.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,345,784 13,941,377
migrations 1,127,820 1,157,323
faults 374,736 382,175
cache-misses 55,132,054,603 54,993,823,500
sched:sched_move_numa 1,923 2,005
sched:sched_stick_numa 52 14
sched:sched_swap_numa 595 529
migrate:mm_migrate_pages 1,932 1,573
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 60605 67099
numa_hint_faults_local 51804 58456
numa_hit 239945 240416
numa_huge_pte_updates 14 18
numa_interleave 60 65
numa_local 239865 240339
numa_other 80 77
numa_pages_migrated 1931 1574
numa_pte_updates 67823 77182
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,016,467 3,176,453
migrations 37,326 30,238
faults 115,342 87,869
cache-misses 11,692,155,554 12,544,479,391
sched:sched_move_numa 965 23
sched:sched_stick_numa 8 0
sched:sched_swap_numa 35 6
migrate:mm_migrate_pages 1,168 10
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 16286 236
numa_hint_faults_local 11863 201
numa_hit 112482 72293
numa_huge_pte_updates 33 0
numa_interleave 20 26
numa_local 112419 72233
numa_other 63 60
numa_pages_migrated 1144 8
numa_pte_updates 32859 0
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,629,724 8,478,820
migrations 221,052 171,323
faults 308,661 307,499
cache-misses 135,574,913 240,353,599
sched:sched_move_numa 147 214
sched:sched_stick_numa 0 0
sched:sched_swap_numa 2 4
migrate:mm_migrate_pages 64 89
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11481 5301
numa_hint_faults_local 10968 4745
numa_hit 89773 92943
numa_huge_pte_updates 0 0
numa_interleave 1116 899
numa_local 89220 92345
numa_other 553 598
numa_pages_migrated 62 88
numa_pte_updates 11694 5505
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,272,887 2,066,172
migrations 12,206 11,076
faults 163,704 149,544
cache-misses 4,801,186 10,398,067
sched:sched_move_numa 44 43
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 17 6
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 2261 3552
numa_hint_faults_local 1993 3347
numa_hit 25726 25611
numa_huge_pte_updates 0 0
numa_interleave 239 213
numa_local 25498 25583
numa_other 228 28
numa_pages_migrated 17 6
numa_pte_updates 2266 3535
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 117,980,962 99,358,136
migrations 3,950,220 4,041,607
faults 736,979 749,653
cache-misses 224,976,072,879 225,562,543,251
sched:sched_move_numa 504 771
sched:sched_stick_numa 50 14
sched:sched_swap_numa 239 204
migrate:mm_migrate_pages 1,260 1,180
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 18293 27409
numa_hint_faults_local 11969 20677
numa_hit 240854 239988
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 240851 239983
numa_other 3 5
numa_pages_migrated 1190 1016
numa_pte_updates 18106 27916
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 61,053,158 60,899,307
migrations 551,586 544,668
faults 244,174 270,834
cache-misses 74,326,766,973 74,543,455,635
sched:sched_move_numa 344 735
sched:sched_stick_numa 24 25
sched:sched_swap_numa 140 174
migrate:mm_migrate_pages 568 816
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 6461 11059
numa_hint_faults_local 2283 4733
numa_hit 35661 41384
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 35661 41383
numa_other 0 1
numa_pages_migrated 568 815
numa_pte_updates 6518 11323
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Rik van Riel <riel@surriel.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-2-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:56 +00:00
|
|
|
struct rq *rq = cpu_rq(env->dst_cpu);
|
|
|
|
|
|
|
|
/* Bail out if run-queue part of active NUMA balance. */
|
|
|
|
if (xchg(&rq->numa_migrate_on, 1))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clear previous best_cpu/rq numa-migrate flag, since task now
|
|
|
|
* found a better CPU to move/swap.
|
|
|
|
*/
|
|
|
|
if (env->best_cpu != -1) {
|
|
|
|
rq = cpu_rq(env->best_cpu);
|
|
|
|
WRITE_ONCE(rq->numa_migrate_on, 0);
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:17 +00:00
|
|
|
if (env->best_task)
|
|
|
|
put_task_struct(env->best_task);
|
2016-05-18 19:57:33 +00:00
|
|
|
if (p)
|
|
|
|
get_task_struct(p);
|
2013-10-07 10:29:17 +00:00
|
|
|
|
|
|
|
env->best_task = p;
|
|
|
|
env->best_imp = imp;
|
|
|
|
env->best_cpu = env->dst_cpu;
|
|
|
|
}
|
|
|
|
|
2014-06-23 15:46:13 +00:00
|
|
|
static bool load_too_imbalanced(long src_load, long dst_load,
|
2014-05-14 17:22:21 +00:00
|
|
|
struct task_numa_env *env)
|
|
|
|
{
|
2015-05-27 19:04:27 +00:00
|
|
|
long imb, old_imb;
|
|
|
|
long orig_src_load, orig_dst_load;
|
2014-06-23 15:46:13 +00:00
|
|
|
long src_capacity, dst_capacity;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The load is corrected for the CPU capacity available on each node.
|
|
|
|
*
|
|
|
|
* src_load dst_load
|
|
|
|
* ------------ vs ---------
|
|
|
|
* src_capacity dst_capacity
|
|
|
|
*/
|
|
|
|
src_capacity = env->src_stats.compute_capacity;
|
|
|
|
dst_capacity = env->dst_stats.compute_capacity;
|
2014-05-14 17:22:21 +00:00
|
|
|
|
2018-06-20 17:02:44 +00:00
|
|
|
imb = abs(dst_load * src_capacity - src_load * dst_capacity);
|
2014-05-14 17:22:21 +00:00
|
|
|
|
2014-06-23 15:46:13 +00:00
|
|
|
orig_src_load = env->src_stats.load;
|
2015-05-27 19:04:27 +00:00
|
|
|
orig_dst_load = env->dst_stats.load;
|
2014-06-23 15:46:13 +00:00
|
|
|
|
2018-06-20 17:02:44 +00:00
|
|
|
old_imb = abs(orig_dst_load * src_capacity - orig_src_load * dst_capacity);
|
2015-05-27 19:04:27 +00:00
|
|
|
|
|
|
|
/* Would this change make things worse? */
|
|
|
|
return (imb > old_imb);
|
2014-05-14 17:22:21 +00:00
|
|
|
}
|
|
|
|
|
sched/numa: Avoid task migration for small NUMA improvement
If NUMA improvement from the task migration is going to be very
minimal, then avoid task migration.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 198512 205910 3.72673
1 313559 318491 1.57291
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
8 74761.9 74935.9 0.232739
1 214874 226796 5.54837
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 180536 189780 5.12031
1 210281 205695 -2.18089
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 56511.4 60370 6.828
1 104899 108100 3.05151
1/7 cases is regressing, if we look at events migrate_pages seem
to vary the most especially in the regressing case. Also some
amount of variance is expected between different runs of
Specjbb2005.
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,818,546 13,801,554
migrations 1,149,960 1,151,541
faults 385,583 433,246
cache-misses 55,259,546,768 55,168,691,835
sched:sched_move_numa 2,257 2,551
sched:sched_stick_numa 9 24
sched:sched_swap_numa 512 904
migrate:mm_migrate_pages 2,225 1,571
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 72692 113682
numa_hint_faults_local 62270 102163
numa_hit 238762 240181
numa_huge_pte_updates 48 36
numa_interleave 75 64
numa_local 238676 240103
numa_other 86 78
numa_pages_migrated 2225 1564
numa_pte_updates 98557 134080
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,173,490 3,079,150
migrations 36,966 31,455
faults 108,776 99,081
cache-misses 12,200,075,320 11,588,126,740
sched:sched_move_numa 1,264 1
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 899 36
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 21109 430
numa_hint_faults_local 17120 77
numa_hit 72934 71277
numa_huge_pte_updates 42 0
numa_interleave 33 22
numa_local 72866 71218
numa_other 68 59
numa_pages_migrated 915 23
numa_pte_updates 42326 0
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,312,022 8,707,565
migrations 231,705 171,342
faults 310,242 310,820
cache-misses 402,324,573 136,115,400
sched:sched_move_numa 193 215
sched:sched_stick_numa 0 6
sched:sched_swap_numa 3 24
migrate:mm_migrate_pages 93 162
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11838 8985
numa_hint_faults_local 11216 8154
numa_hit 90689 93819
numa_huge_pte_updates 0 0
numa_interleave 1579 882
numa_local 89634 93496
numa_other 1055 323
numa_pages_migrated 92 169
numa_pte_updates 12109 9217
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,170,481 2,152,072
migrations 10,126 10,704
faults 160,962 164,376
cache-misses 10,834,845 3,818,437
sched:sched_move_numa 10 16
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 7
migrate:mm_migrate_pages 2 199
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 403 2248
numa_hint_faults_local 358 1666
numa_hit 25898 25704
numa_huge_pte_updates 0 0
numa_interleave 207 200
numa_local 25860 25679
numa_other 38 25
numa_pages_migrated 2 197
numa_pte_updates 400 2234
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 110,339,633 93,330,595
migrations 4,139,812 4,122,061
faults 863,622 865,979
cache-misses 231,838,045,660 225,395,083,479
sched:sched_move_numa 2,196 2,372
sched:sched_stick_numa 33 24
sched:sched_swap_numa 544 769
migrate:mm_migrate_pages 2,469 1,677
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 85748 91638
numa_hint_faults_local 66831 78096
numa_hit 242213 242225
numa_huge_pte_updates 0 0
numa_interleave 0 2
numa_local 242211 242219
numa_other 2 6
numa_pages_migrated 2376 1515
numa_pte_updates 86233 92274
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 59,331,057 51,487,271
migrations 552,019 537,170
faults 266,586 256,921
cache-misses 73,796,312,990 70,073,831,187
sched:sched_move_numa 981 576
sched:sched_stick_numa 54 24
sched:sched_swap_numa 286 327
migrate:mm_migrate_pages 713 726
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 14807 12000
numa_hint_faults_local 5738 5024
numa_hit 36230 36470
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 36228 36465
numa_other 2 5
numa_pages_migrated 703 726
numa_pte_updates 14742 11930
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-7-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:49:01 +00:00
|
|
|
/*
|
|
|
|
* Maximum NUMA importance can be 1998 (2*999);
|
|
|
|
* SMALLIMP @ 30 would be close to 1998/64.
|
|
|
|
* Used to deter task migration.
|
|
|
|
*/
|
|
|
|
#define SMALLIMP 30
|
|
|
|
|
2013-10-07 10:29:17 +00:00
|
|
|
/*
|
|
|
|
* This checks if the overall compute and NUMA accesses of the system would
|
|
|
|
* be improved if the source tasks was migrated to the target dst_cpu taking
|
|
|
|
* into account that it might be best if task running on the dst_cpu should
|
|
|
|
* be exchanged with the source task
|
|
|
|
*/
|
2013-10-07 10:29:31 +00:00
|
|
|
static void task_numa_compare(struct task_numa_env *env,
|
2018-06-20 17:02:43 +00:00
|
|
|
long taskimp, long groupimp, bool maymove)
|
2013-10-07 10:29:17 +00:00
|
|
|
{
|
2019-07-16 15:20:47 +00:00
|
|
|
struct numa_group *cur_ng, *p_ng = deref_curr_numa_group(env->p);
|
2013-10-07 10:29:17 +00:00
|
|
|
struct rq *dst_rq = cpu_rq(env->dst_cpu);
|
2019-07-16 15:20:47 +00:00
|
|
|
long imp = p_ng ? groupimp : taskimp;
|
2013-10-07 10:29:17 +00:00
|
|
|
struct task_struct *cur;
|
2014-06-23 15:46:13 +00:00
|
|
|
long src_load, dst_load;
|
2014-10-17 07:29:51 +00:00
|
|
|
int dist = env->dist;
|
2019-07-16 15:20:47 +00:00
|
|
|
long moveimp = imp;
|
|
|
|
long load;
|
2013-10-07 10:29:17 +00:00
|
|
|
|
sched/numa: Stop multiple tasks from moving to the CPU at the same time
Task migration under NUMA balancing can happen in parallel. More than
one task might choose to migrate to the same CPU at the same time. This
can result in:
- During task swap, choosing a task that was not part of the evaluation.
- During task swap, task which just got moved into its preferred node,
moving to a completely different node.
- During task swap, task failing to move to the preferred node, will have
to wait an extra interval for the next migrate opportunity.
- During task movement, multiple task movements can cause load imbalance.
This problem is more likely if there are more cores per node or more
nodes in the system.
Use a per run-queue variable to check if NUMA-balance is active on the
run-queue.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200194 203353 1.57797
1 311331 328205 5.41995
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 197654 214384 8.46429
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 192605 188553 -2.10379
1 213402 196273 -8.02664
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 52227.1 57581.2 10.2516
1 102529 103468 0.915838
There is a regression on power 9 box. If we look at the details,
that box has a sudden jump in cache-misses with this patch.
All other parameters seem to be pointing towards NUMA
consolidation.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,345,784 13,941,377
migrations 1,127,820 1,157,323
faults 374,736 382,175
cache-misses 55,132,054,603 54,993,823,500
sched:sched_move_numa 1,923 2,005
sched:sched_stick_numa 52 14
sched:sched_swap_numa 595 529
migrate:mm_migrate_pages 1,932 1,573
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 60605 67099
numa_hint_faults_local 51804 58456
numa_hit 239945 240416
numa_huge_pte_updates 14 18
numa_interleave 60 65
numa_local 239865 240339
numa_other 80 77
numa_pages_migrated 1931 1574
numa_pte_updates 67823 77182
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,016,467 3,176,453
migrations 37,326 30,238
faults 115,342 87,869
cache-misses 11,692,155,554 12,544,479,391
sched:sched_move_numa 965 23
sched:sched_stick_numa 8 0
sched:sched_swap_numa 35 6
migrate:mm_migrate_pages 1,168 10
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 16286 236
numa_hint_faults_local 11863 201
numa_hit 112482 72293
numa_huge_pte_updates 33 0
numa_interleave 20 26
numa_local 112419 72233
numa_other 63 60
numa_pages_migrated 1144 8
numa_pte_updates 32859 0
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,629,724 8,478,820
migrations 221,052 171,323
faults 308,661 307,499
cache-misses 135,574,913 240,353,599
sched:sched_move_numa 147 214
sched:sched_stick_numa 0 0
sched:sched_swap_numa 2 4
migrate:mm_migrate_pages 64 89
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11481 5301
numa_hint_faults_local 10968 4745
numa_hit 89773 92943
numa_huge_pte_updates 0 0
numa_interleave 1116 899
numa_local 89220 92345
numa_other 553 598
numa_pages_migrated 62 88
numa_pte_updates 11694 5505
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,272,887 2,066,172
migrations 12,206 11,076
faults 163,704 149,544
cache-misses 4,801,186 10,398,067
sched:sched_move_numa 44 43
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 17 6
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 2261 3552
numa_hint_faults_local 1993 3347
numa_hit 25726 25611
numa_huge_pte_updates 0 0
numa_interleave 239 213
numa_local 25498 25583
numa_other 228 28
numa_pages_migrated 17 6
numa_pte_updates 2266 3535
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 117,980,962 99,358,136
migrations 3,950,220 4,041,607
faults 736,979 749,653
cache-misses 224,976,072,879 225,562,543,251
sched:sched_move_numa 504 771
sched:sched_stick_numa 50 14
sched:sched_swap_numa 239 204
migrate:mm_migrate_pages 1,260 1,180
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 18293 27409
numa_hint_faults_local 11969 20677
numa_hit 240854 239988
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 240851 239983
numa_other 3 5
numa_pages_migrated 1190 1016
numa_pte_updates 18106 27916
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 61,053,158 60,899,307
migrations 551,586 544,668
faults 244,174 270,834
cache-misses 74,326,766,973 74,543,455,635
sched:sched_move_numa 344 735
sched:sched_stick_numa 24 25
sched:sched_swap_numa 140 174
migrate:mm_migrate_pages 568 816
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 6461 11059
numa_hint_faults_local 2283 4733
numa_hit 35661 41384
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 35661 41383
numa_other 0 1
numa_pages_migrated 568 815
numa_pte_updates 6518 11323
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Rik van Riel <riel@surriel.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-2-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:56 +00:00
|
|
|
if (READ_ONCE(dst_rq->numa_migrate_on))
|
|
|
|
return;
|
|
|
|
|
2013-10-07 10:29:17 +00:00
|
|
|
rcu_read_lock();
|
2019-09-14 12:34:30 +00:00
|
|
|
cur = rcu_dereference(dst_rq->curr);
|
2016-05-18 19:57:33 +00:00
|
|
|
if (cur && ((cur->flags & PF_EXITING) || is_idle_task(cur)))
|
2013-10-07 10:29:17 +00:00
|
|
|
cur = NULL;
|
|
|
|
|
2014-11-10 09:54:35 +00:00
|
|
|
/*
|
|
|
|
* Because we have preemption enabled we can get migrated around and
|
|
|
|
* end try selecting ourselves (current == env->p) as a swap candidate.
|
|
|
|
*/
|
|
|
|
if (cur == env->p)
|
|
|
|
goto unlock;
|
|
|
|
|
2018-06-20 17:02:43 +00:00
|
|
|
if (!cur) {
|
sched/numa: Avoid task migration for small NUMA improvement
If NUMA improvement from the task migration is going to be very
minimal, then avoid task migration.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 198512 205910 3.72673
1 313559 318491 1.57291
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
8 74761.9 74935.9 0.232739
1 214874 226796 5.54837
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 180536 189780 5.12031
1 210281 205695 -2.18089
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 56511.4 60370 6.828
1 104899 108100 3.05151
1/7 cases is regressing, if we look at events migrate_pages seem
to vary the most especially in the regressing case. Also some
amount of variance is expected between different runs of
Specjbb2005.
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,818,546 13,801,554
migrations 1,149,960 1,151,541
faults 385,583 433,246
cache-misses 55,259,546,768 55,168,691,835
sched:sched_move_numa 2,257 2,551
sched:sched_stick_numa 9 24
sched:sched_swap_numa 512 904
migrate:mm_migrate_pages 2,225 1,571
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 72692 113682
numa_hint_faults_local 62270 102163
numa_hit 238762 240181
numa_huge_pte_updates 48 36
numa_interleave 75 64
numa_local 238676 240103
numa_other 86 78
numa_pages_migrated 2225 1564
numa_pte_updates 98557 134080
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,173,490 3,079,150
migrations 36,966 31,455
faults 108,776 99,081
cache-misses 12,200,075,320 11,588,126,740
sched:sched_move_numa 1,264 1
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 899 36
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 21109 430
numa_hint_faults_local 17120 77
numa_hit 72934 71277
numa_huge_pte_updates 42 0
numa_interleave 33 22
numa_local 72866 71218
numa_other 68 59
numa_pages_migrated 915 23
numa_pte_updates 42326 0
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,312,022 8,707,565
migrations 231,705 171,342
faults 310,242 310,820
cache-misses 402,324,573 136,115,400
sched:sched_move_numa 193 215
sched:sched_stick_numa 0 6
sched:sched_swap_numa 3 24
migrate:mm_migrate_pages 93 162
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11838 8985
numa_hint_faults_local 11216 8154
numa_hit 90689 93819
numa_huge_pte_updates 0 0
numa_interleave 1579 882
numa_local 89634 93496
numa_other 1055 323
numa_pages_migrated 92 169
numa_pte_updates 12109 9217
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,170,481 2,152,072
migrations 10,126 10,704
faults 160,962 164,376
cache-misses 10,834,845 3,818,437
sched:sched_move_numa 10 16
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 7
migrate:mm_migrate_pages 2 199
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 403 2248
numa_hint_faults_local 358 1666
numa_hit 25898 25704
numa_huge_pte_updates 0 0
numa_interleave 207 200
numa_local 25860 25679
numa_other 38 25
numa_pages_migrated 2 197
numa_pte_updates 400 2234
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 110,339,633 93,330,595
migrations 4,139,812 4,122,061
faults 863,622 865,979
cache-misses 231,838,045,660 225,395,083,479
sched:sched_move_numa 2,196 2,372
sched:sched_stick_numa 33 24
sched:sched_swap_numa 544 769
migrate:mm_migrate_pages 2,469 1,677
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 85748 91638
numa_hint_faults_local 66831 78096
numa_hit 242213 242225
numa_huge_pte_updates 0 0
numa_interleave 0 2
numa_local 242211 242219
numa_other 2 6
numa_pages_migrated 2376 1515
numa_pte_updates 86233 92274
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 59,331,057 51,487,271
migrations 552,019 537,170
faults 266,586 256,921
cache-misses 73,796,312,990 70,073,831,187
sched:sched_move_numa 981 576
sched:sched_stick_numa 54 24
sched:sched_swap_numa 286 327
migrate:mm_migrate_pages 713 726
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 14807 12000
numa_hint_faults_local 5738 5024
numa_hit 36230 36470
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 36228 36465
numa_other 2 5
numa_pages_migrated 703 726
numa_pte_updates 14742 11930
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-7-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:49:01 +00:00
|
|
|
if (maymove && moveimp >= env->best_imp)
|
2018-06-20 17:02:43 +00:00
|
|
|
goto assign;
|
|
|
|
else
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:17 +00:00
|
|
|
/*
|
|
|
|
* "imp" is the fault differential for the source task between the
|
|
|
|
* source and destination node. Calculate the total differential for
|
|
|
|
* the source task and potential destination task. The more negative
|
2018-06-20 17:02:43 +00:00
|
|
|
* the value is, the more remote accesses that would be expected to
|
2013-10-07 10:29:17 +00:00
|
|
|
* be incurred if the tasks were swapped.
|
|
|
|
*/
|
2018-06-20 17:02:43 +00:00
|
|
|
/* Skip this swap candidate if cannot move to the source cpu */
|
2019-04-23 14:26:36 +00:00
|
|
|
if (!cpumask_test_cpu(env->src_cpu, cur->cpus_ptr))
|
2018-06-20 17:02:43 +00:00
|
|
|
goto unlock;
|
2013-10-07 10:29:17 +00:00
|
|
|
|
2018-06-20 17:02:43 +00:00
|
|
|
/*
|
|
|
|
* If dst and source tasks are in the same NUMA group, or not
|
|
|
|
* in any group then look only at task weights.
|
|
|
|
*/
|
2019-07-16 15:20:47 +00:00
|
|
|
cur_ng = rcu_dereference(cur->numa_group);
|
|
|
|
if (cur_ng == p_ng) {
|
2018-06-20 17:02:43 +00:00
|
|
|
imp = taskimp + task_weight(cur, env->src_nid, dist) -
|
|
|
|
task_weight(cur, env->dst_nid, dist);
|
2013-10-07 10:29:31 +00:00
|
|
|
/*
|
2018-06-20 17:02:43 +00:00
|
|
|
* Add some hysteresis to prevent swapping the
|
|
|
|
* tasks within a group over tiny differences.
|
2013-10-07 10:29:31 +00:00
|
|
|
*/
|
2019-07-16 15:20:47 +00:00
|
|
|
if (cur_ng)
|
2018-06-20 17:02:43 +00:00
|
|
|
imp -= imp / 16;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Compare the group weights. If a task is all by itself
|
|
|
|
* (not part of a group), use the task weight instead.
|
|
|
|
*/
|
2019-07-16 15:20:47 +00:00
|
|
|
if (cur_ng && p_ng)
|
2018-06-20 17:02:43 +00:00
|
|
|
imp += group_weight(cur, env->src_nid, dist) -
|
|
|
|
group_weight(cur, env->dst_nid, dist);
|
|
|
|
else
|
|
|
|
imp += task_weight(cur, env->src_nid, dist) -
|
|
|
|
task_weight(cur, env->dst_nid, dist);
|
2013-10-07 10:29:17 +00:00
|
|
|
}
|
|
|
|
|
2018-06-20 17:02:43 +00:00
|
|
|
if (maymove && moveimp > imp && moveimp > env->best_imp) {
|
sched/numa: Avoid task migration for small NUMA improvement
If NUMA improvement from the task migration is going to be very
minimal, then avoid task migration.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 198512 205910 3.72673
1 313559 318491 1.57291
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
8 74761.9 74935.9 0.232739
1 214874 226796 5.54837
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 180536 189780 5.12031
1 210281 205695 -2.18089
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 56511.4 60370 6.828
1 104899 108100 3.05151
1/7 cases is regressing, if we look at events migrate_pages seem
to vary the most especially in the regressing case. Also some
amount of variance is expected between different runs of
Specjbb2005.
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,818,546 13,801,554
migrations 1,149,960 1,151,541
faults 385,583 433,246
cache-misses 55,259,546,768 55,168,691,835
sched:sched_move_numa 2,257 2,551
sched:sched_stick_numa 9 24
sched:sched_swap_numa 512 904
migrate:mm_migrate_pages 2,225 1,571
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 72692 113682
numa_hint_faults_local 62270 102163
numa_hit 238762 240181
numa_huge_pte_updates 48 36
numa_interleave 75 64
numa_local 238676 240103
numa_other 86 78
numa_pages_migrated 2225 1564
numa_pte_updates 98557 134080
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,173,490 3,079,150
migrations 36,966 31,455
faults 108,776 99,081
cache-misses 12,200,075,320 11,588,126,740
sched:sched_move_numa 1,264 1
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 899 36
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 21109 430
numa_hint_faults_local 17120 77
numa_hit 72934 71277
numa_huge_pte_updates 42 0
numa_interleave 33 22
numa_local 72866 71218
numa_other 68 59
numa_pages_migrated 915 23
numa_pte_updates 42326 0
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,312,022 8,707,565
migrations 231,705 171,342
faults 310,242 310,820
cache-misses 402,324,573 136,115,400
sched:sched_move_numa 193 215
sched:sched_stick_numa 0 6
sched:sched_swap_numa 3 24
migrate:mm_migrate_pages 93 162
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11838 8985
numa_hint_faults_local 11216 8154
numa_hit 90689 93819
numa_huge_pte_updates 0 0
numa_interleave 1579 882
numa_local 89634 93496
numa_other 1055 323
numa_pages_migrated 92 169
numa_pte_updates 12109 9217
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,170,481 2,152,072
migrations 10,126 10,704
faults 160,962 164,376
cache-misses 10,834,845 3,818,437
sched:sched_move_numa 10 16
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 7
migrate:mm_migrate_pages 2 199
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 403 2248
numa_hint_faults_local 358 1666
numa_hit 25898 25704
numa_huge_pte_updates 0 0
numa_interleave 207 200
numa_local 25860 25679
numa_other 38 25
numa_pages_migrated 2 197
numa_pte_updates 400 2234
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 110,339,633 93,330,595
migrations 4,139,812 4,122,061
faults 863,622 865,979
cache-misses 231,838,045,660 225,395,083,479
sched:sched_move_numa 2,196 2,372
sched:sched_stick_numa 33 24
sched:sched_swap_numa 544 769
migrate:mm_migrate_pages 2,469 1,677
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 85748 91638
numa_hint_faults_local 66831 78096
numa_hit 242213 242225
numa_huge_pte_updates 0 0
numa_interleave 0 2
numa_local 242211 242219
numa_other 2 6
numa_pages_migrated 2376 1515
numa_pte_updates 86233 92274
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 59,331,057 51,487,271
migrations 552,019 537,170
faults 266,586 256,921
cache-misses 73,796,312,990 70,073,831,187
sched:sched_move_numa 981 576
sched:sched_stick_numa 54 24
sched:sched_swap_numa 286 327
migrate:mm_migrate_pages 713 726
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 14807 12000
numa_hint_faults_local 5738 5024
numa_hit 36230 36470
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 36228 36465
numa_other 2 5
numa_pages_migrated 703 726
numa_pte_updates 14742 11930
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-7-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:49:01 +00:00
|
|
|
imp = moveimp;
|
2018-06-20 17:02:43 +00:00
|
|
|
cur = NULL;
|
2013-10-07 10:29:17 +00:00
|
|
|
goto assign;
|
2018-06-20 17:02:43 +00:00
|
|
|
}
|
2013-10-07 10:29:17 +00:00
|
|
|
|
sched/numa: Avoid task migration for small NUMA improvement
If NUMA improvement from the task migration is going to be very
minimal, then avoid task migration.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 198512 205910 3.72673
1 313559 318491 1.57291
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
8 74761.9 74935.9 0.232739
1 214874 226796 5.54837
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 180536 189780 5.12031
1 210281 205695 -2.18089
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 56511.4 60370 6.828
1 104899 108100 3.05151
1/7 cases is regressing, if we look at events migrate_pages seem
to vary the most especially in the regressing case. Also some
amount of variance is expected between different runs of
Specjbb2005.
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,818,546 13,801,554
migrations 1,149,960 1,151,541
faults 385,583 433,246
cache-misses 55,259,546,768 55,168,691,835
sched:sched_move_numa 2,257 2,551
sched:sched_stick_numa 9 24
sched:sched_swap_numa 512 904
migrate:mm_migrate_pages 2,225 1,571
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 72692 113682
numa_hint_faults_local 62270 102163
numa_hit 238762 240181
numa_huge_pte_updates 48 36
numa_interleave 75 64
numa_local 238676 240103
numa_other 86 78
numa_pages_migrated 2225 1564
numa_pte_updates 98557 134080
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,173,490 3,079,150
migrations 36,966 31,455
faults 108,776 99,081
cache-misses 12,200,075,320 11,588,126,740
sched:sched_move_numa 1,264 1
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 899 36
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 21109 430
numa_hint_faults_local 17120 77
numa_hit 72934 71277
numa_huge_pte_updates 42 0
numa_interleave 33 22
numa_local 72866 71218
numa_other 68 59
numa_pages_migrated 915 23
numa_pte_updates 42326 0
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,312,022 8,707,565
migrations 231,705 171,342
faults 310,242 310,820
cache-misses 402,324,573 136,115,400
sched:sched_move_numa 193 215
sched:sched_stick_numa 0 6
sched:sched_swap_numa 3 24
migrate:mm_migrate_pages 93 162
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11838 8985
numa_hint_faults_local 11216 8154
numa_hit 90689 93819
numa_huge_pte_updates 0 0
numa_interleave 1579 882
numa_local 89634 93496
numa_other 1055 323
numa_pages_migrated 92 169
numa_pte_updates 12109 9217
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,170,481 2,152,072
migrations 10,126 10,704
faults 160,962 164,376
cache-misses 10,834,845 3,818,437
sched:sched_move_numa 10 16
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 7
migrate:mm_migrate_pages 2 199
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 403 2248
numa_hint_faults_local 358 1666
numa_hit 25898 25704
numa_huge_pte_updates 0 0
numa_interleave 207 200
numa_local 25860 25679
numa_other 38 25
numa_pages_migrated 2 197
numa_pte_updates 400 2234
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 110,339,633 93,330,595
migrations 4,139,812 4,122,061
faults 863,622 865,979
cache-misses 231,838,045,660 225,395,083,479
sched:sched_move_numa 2,196 2,372
sched:sched_stick_numa 33 24
sched:sched_swap_numa 544 769
migrate:mm_migrate_pages 2,469 1,677
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 85748 91638
numa_hint_faults_local 66831 78096
numa_hit 242213 242225
numa_huge_pte_updates 0 0
numa_interleave 0 2
numa_local 242211 242219
numa_other 2 6
numa_pages_migrated 2376 1515
numa_pte_updates 86233 92274
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 59,331,057 51,487,271
migrations 552,019 537,170
faults 266,586 256,921
cache-misses 73,796,312,990 70,073,831,187
sched:sched_move_numa 981 576
sched:sched_stick_numa 54 24
sched:sched_swap_numa 286 327
migrate:mm_migrate_pages 713 726
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 14807 12000
numa_hint_faults_local 5738 5024
numa_hit 36230 36470
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 36228 36465
numa_other 2 5
numa_pages_migrated 703 726
numa_pte_updates 14742 11930
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-7-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:49:01 +00:00
|
|
|
/*
|
|
|
|
* If the NUMA importance is less than SMALLIMP,
|
|
|
|
* task migration might only result in ping pong
|
|
|
|
* of tasks and also hurt performance due to cache
|
|
|
|
* misses.
|
|
|
|
*/
|
|
|
|
if (imp < SMALLIMP || imp <= env->best_imp + SMALLIMP / 2)
|
|
|
|
goto unlock;
|
|
|
|
|
2013-10-07 10:29:17 +00:00
|
|
|
/*
|
|
|
|
* In the overloaded case, try and keep the load balanced.
|
|
|
|
*/
|
2018-06-20 17:02:43 +00:00
|
|
|
load = task_h_load(env->p) - task_h_load(cur);
|
|
|
|
if (!load)
|
|
|
|
goto assign;
|
|
|
|
|
2014-07-11 14:01:53 +00:00
|
|
|
dst_load = env->dst_stats.load + load;
|
|
|
|
src_load = env->src_stats.load - load;
|
2013-10-07 10:29:17 +00:00
|
|
|
|
2014-06-23 15:46:13 +00:00
|
|
|
if (load_too_imbalanced(src_load, dst_load, env))
|
2013-10-07 10:29:17 +00:00
|
|
|
goto unlock;
|
|
|
|
|
2018-06-20 17:02:43 +00:00
|
|
|
assign:
|
2014-09-04 20:35:30 +00:00
|
|
|
/*
|
|
|
|
* One idle CPU per node is evaluated for a task numa move.
|
|
|
|
* Call select_idle_sibling to maybe find a better one.
|
|
|
|
*/
|
2016-05-09 08:38:05 +00:00
|
|
|
if (!cur) {
|
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* select_idle_siblings() uses an per-CPU cpumask that
|
2016-05-09 08:38:05 +00:00
|
|
|
* can be used from IRQ context.
|
|
|
|
*/
|
|
|
|
local_irq_disable();
|
2016-06-22 17:03:13 +00:00
|
|
|
env->dst_cpu = select_idle_sibling(env->p, env->src_cpu,
|
|
|
|
env->dst_cpu);
|
2016-05-09 08:38:05 +00:00
|
|
|
local_irq_enable();
|
|
|
|
}
|
2014-09-04 20:35:30 +00:00
|
|
|
|
2013-10-07 10:29:17 +00:00
|
|
|
task_numa_assign(env, cur, imp);
|
|
|
|
unlock:
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:31 +00:00
|
|
|
static void task_numa_find_cpu(struct task_numa_env *env,
|
|
|
|
long taskimp, long groupimp)
|
2013-10-07 10:29:18 +00:00
|
|
|
{
|
2018-06-20 17:02:43 +00:00
|
|
|
long src_load, dst_load, load;
|
|
|
|
bool maymove = false;
|
2013-10-07 10:29:18 +00:00
|
|
|
int cpu;
|
|
|
|
|
2018-06-20 17:02:43 +00:00
|
|
|
load = task_h_load(env->p);
|
|
|
|
dst_load = env->dst_stats.load + load;
|
|
|
|
src_load = env->src_stats.load - load;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the improvement from just moving env->p direction is better
|
|
|
|
* than swapping tasks around, check if a move is possible.
|
|
|
|
*/
|
|
|
|
maymove = !load_too_imbalanced(src_load, dst_load, env);
|
|
|
|
|
2013-10-07 10:29:18 +00:00
|
|
|
for_each_cpu(cpu, cpumask_of_node(env->dst_nid)) {
|
|
|
|
/* Skip this CPU if the source task cannot migrate */
|
2019-04-23 14:26:36 +00:00
|
|
|
if (!cpumask_test_cpu(cpu, env->p->cpus_ptr))
|
2013-10-07 10:29:18 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
env->dst_cpu = cpu;
|
2018-06-20 17:02:43 +00:00
|
|
|
task_numa_compare(env, taskimp, groupimp, maymove);
|
2013-10-07 10:29:18 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:10 +00:00
|
|
|
static int task_numa_migrate(struct task_struct *p)
|
|
|
|
{
|
|
|
|
struct task_numa_env env = {
|
|
|
|
.p = p,
|
2013-10-07 10:29:17 +00:00
|
|
|
|
2013-10-07 10:29:10 +00:00
|
|
|
.src_cpu = task_cpu(p),
|
2013-10-07 10:29:30 +00:00
|
|
|
.src_nid = task_node(p),
|
2013-10-07 10:29:17 +00:00
|
|
|
|
|
|
|
.imbalance_pct = 112,
|
|
|
|
|
|
|
|
.best_task = NULL,
|
|
|
|
.best_imp = 0,
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
.best_cpu = -1,
|
2013-10-07 10:29:10 +00:00
|
|
|
};
|
2019-07-16 15:20:47 +00:00
|
|
|
unsigned long taskweight, groupweight;
|
2013-10-07 10:29:10 +00:00
|
|
|
struct sched_domain *sd;
|
2019-07-16 15:20:47 +00:00
|
|
|
long taskimp, groupimp;
|
|
|
|
struct numa_group *ng;
|
sched/numa: Stop multiple tasks from moving to the CPU at the same time
Task migration under NUMA balancing can happen in parallel. More than
one task might choose to migrate to the same CPU at the same time. This
can result in:
- During task swap, choosing a task that was not part of the evaluation.
- During task swap, task which just got moved into its preferred node,
moving to a completely different node.
- During task swap, task failing to move to the preferred node, will have
to wait an extra interval for the next migrate opportunity.
- During task movement, multiple task movements can cause load imbalance.
This problem is more likely if there are more cores per node or more
nodes in the system.
Use a per run-queue variable to check if NUMA-balance is active on the
run-queue.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200194 203353 1.57797
1 311331 328205 5.41995
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 197654 214384 8.46429
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 192605 188553 -2.10379
1 213402 196273 -8.02664
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 52227.1 57581.2 10.2516
1 102529 103468 0.915838
There is a regression on power 9 box. If we look at the details,
that box has a sudden jump in cache-misses with this patch.
All other parameters seem to be pointing towards NUMA
consolidation.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,345,784 13,941,377
migrations 1,127,820 1,157,323
faults 374,736 382,175
cache-misses 55,132,054,603 54,993,823,500
sched:sched_move_numa 1,923 2,005
sched:sched_stick_numa 52 14
sched:sched_swap_numa 595 529
migrate:mm_migrate_pages 1,932 1,573
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 60605 67099
numa_hint_faults_local 51804 58456
numa_hit 239945 240416
numa_huge_pte_updates 14 18
numa_interleave 60 65
numa_local 239865 240339
numa_other 80 77
numa_pages_migrated 1931 1574
numa_pte_updates 67823 77182
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,016,467 3,176,453
migrations 37,326 30,238
faults 115,342 87,869
cache-misses 11,692,155,554 12,544,479,391
sched:sched_move_numa 965 23
sched:sched_stick_numa 8 0
sched:sched_swap_numa 35 6
migrate:mm_migrate_pages 1,168 10
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 16286 236
numa_hint_faults_local 11863 201
numa_hit 112482 72293
numa_huge_pte_updates 33 0
numa_interleave 20 26
numa_local 112419 72233
numa_other 63 60
numa_pages_migrated 1144 8
numa_pte_updates 32859 0
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,629,724 8,478,820
migrations 221,052 171,323
faults 308,661 307,499
cache-misses 135,574,913 240,353,599
sched:sched_move_numa 147 214
sched:sched_stick_numa 0 0
sched:sched_swap_numa 2 4
migrate:mm_migrate_pages 64 89
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11481 5301
numa_hint_faults_local 10968 4745
numa_hit 89773 92943
numa_huge_pte_updates 0 0
numa_interleave 1116 899
numa_local 89220 92345
numa_other 553 598
numa_pages_migrated 62 88
numa_pte_updates 11694 5505
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,272,887 2,066,172
migrations 12,206 11,076
faults 163,704 149,544
cache-misses 4,801,186 10,398,067
sched:sched_move_numa 44 43
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 17 6
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 2261 3552
numa_hint_faults_local 1993 3347
numa_hit 25726 25611
numa_huge_pte_updates 0 0
numa_interleave 239 213
numa_local 25498 25583
numa_other 228 28
numa_pages_migrated 17 6
numa_pte_updates 2266 3535
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 117,980,962 99,358,136
migrations 3,950,220 4,041,607
faults 736,979 749,653
cache-misses 224,976,072,879 225,562,543,251
sched:sched_move_numa 504 771
sched:sched_stick_numa 50 14
sched:sched_swap_numa 239 204
migrate:mm_migrate_pages 1,260 1,180
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 18293 27409
numa_hint_faults_local 11969 20677
numa_hit 240854 239988
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 240851 239983
numa_other 3 5
numa_pages_migrated 1190 1016
numa_pte_updates 18106 27916
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 61,053,158 60,899,307
migrations 551,586 544,668
faults 244,174 270,834
cache-misses 74,326,766,973 74,543,455,635
sched:sched_move_numa 344 735
sched:sched_stick_numa 24 25
sched:sched_swap_numa 140 174
migrate:mm_migrate_pages 568 816
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 6461 11059
numa_hint_faults_local 2283 4733
numa_hit 35661 41384
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 35661 41383
numa_other 0 1
numa_pages_migrated 568 815
numa_pte_updates 6518 11323
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Rik van Riel <riel@surriel.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-2-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:56 +00:00
|
|
|
struct rq *best_rq;
|
2014-10-17 07:29:51 +00:00
|
|
|
int nid, ret, dist;
|
2013-10-07 10:29:02 +00:00
|
|
|
|
2013-10-07 10:29:10 +00:00
|
|
|
/*
|
2013-10-07 10:29:17 +00:00
|
|
|
* Pick the lowest SD_NUMA domain, as that would have the smallest
|
|
|
|
* imbalance and would be the first to start moving tasks about.
|
|
|
|
*
|
|
|
|
* And we want to avoid any moving of tasks about, as that would create
|
|
|
|
* random movement of tasks -- counter the numa conditions we're trying
|
|
|
|
* to satisfy here.
|
2013-10-07 10:29:10 +00:00
|
|
|
*/
|
|
|
|
rcu_read_lock();
|
2013-10-07 10:29:17 +00:00
|
|
|
sd = rcu_dereference(per_cpu(sd_numa, env.src_cpu));
|
2013-11-12 00:29:25 +00:00
|
|
|
if (sd)
|
|
|
|
env.imbalance_pct = 100 + (sd->imbalance_pct - 100) / 2;
|
2013-10-07 10:29:02 +00:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
2013-11-12 00:29:25 +00:00
|
|
|
/*
|
|
|
|
* Cpusets can break the scheduler domain tree into smaller
|
|
|
|
* balance domains, some of which do not cross NUMA boundaries.
|
|
|
|
* Tasks that are "trapped" in such domains cannot be migrated
|
|
|
|
* elsewhere, so there is no point in (re)trying.
|
|
|
|
*/
|
|
|
|
if (unlikely(!sd)) {
|
2018-06-20 17:02:45 +00:00
|
|
|
sched_setnuma(p, task_node(p));
|
2013-11-12 00:29:25 +00:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:18 +00:00
|
|
|
env.dst_nid = p->numa_preferred_nid;
|
2014-10-17 07:29:51 +00:00
|
|
|
dist = env.dist = node_distance(env.src_nid, env.dst_nid);
|
|
|
|
taskweight = task_weight(p, env.src_nid, dist);
|
|
|
|
groupweight = group_weight(p, env.src_nid, dist);
|
|
|
|
update_numa_stats(&env.src_stats, env.src_nid);
|
|
|
|
taskimp = task_weight(p, env.dst_nid, dist) - taskweight;
|
|
|
|
groupimp = group_weight(p, env.dst_nid, dist) - groupweight;
|
2013-10-07 10:29:18 +00:00
|
|
|
update_numa_stats(&env.dst_stats, env.dst_nid);
|
2013-10-07 10:29:10 +00:00
|
|
|
|
2014-06-04 20:09:42 +00:00
|
|
|
/* Try to find a spot on the preferred nid. */
|
2018-06-20 17:02:53 +00:00
|
|
|
task_numa_find_cpu(&env, taskimp, groupimp);
|
2013-10-07 10:29:19 +00:00
|
|
|
|
2014-10-09 21:27:47 +00:00
|
|
|
/*
|
|
|
|
* Look at other nodes in these cases:
|
|
|
|
* - there is no space available on the preferred_nid
|
|
|
|
* - the task is part of a numa_group that is interleaved across
|
|
|
|
* multiple NUMA nodes; in order to better consolidate the group,
|
|
|
|
* we need to check other locations.
|
|
|
|
*/
|
2019-07-16 15:20:47 +00:00
|
|
|
ng = deref_curr_numa_group(p);
|
|
|
|
if (env.best_cpu == -1 || (ng && ng->active_nodes > 1)) {
|
2013-10-07 10:29:18 +00:00
|
|
|
for_each_online_node(nid) {
|
|
|
|
if (nid == env.src_nid || nid == p->numa_preferred_nid)
|
|
|
|
continue;
|
2013-10-07 10:29:10 +00:00
|
|
|
|
2014-10-17 07:29:51 +00:00
|
|
|
dist = node_distance(env.src_nid, env.dst_nid);
|
2014-10-17 07:29:52 +00:00
|
|
|
if (sched_numa_topology_type == NUMA_BACKPLANE &&
|
|
|
|
dist != env.dist) {
|
|
|
|
taskweight = task_weight(p, env.src_nid, dist);
|
|
|
|
groupweight = group_weight(p, env.src_nid, dist);
|
|
|
|
}
|
2014-10-17 07:29:51 +00:00
|
|
|
|
2013-10-07 10:29:27 +00:00
|
|
|
/* Only consider nodes where both task and groups benefit */
|
2014-10-17 07:29:51 +00:00
|
|
|
taskimp = task_weight(p, nid, dist) - taskweight;
|
|
|
|
groupimp = group_weight(p, nid, dist) - groupweight;
|
2013-10-07 10:29:31 +00:00
|
|
|
if (taskimp < 0 && groupimp < 0)
|
2013-10-07 10:29:17 +00:00
|
|
|
continue;
|
|
|
|
|
2014-10-17 07:29:51 +00:00
|
|
|
env.dist = dist;
|
2013-10-07 10:29:18 +00:00
|
|
|
env.dst_nid = nid;
|
|
|
|
update_numa_stats(&env.dst_stats, env.dst_nid);
|
2018-06-20 17:02:53 +00:00
|
|
|
task_numa_find_cpu(&env, taskimp, groupimp);
|
2013-10-07 10:29:10 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-11 17:00:29 +00:00
|
|
|
/*
|
|
|
|
* If the task is part of a workload that spans multiple NUMA nodes,
|
|
|
|
* and is migrating into one of the workload's active nodes, remember
|
|
|
|
* this node as the task's preferred numa node, so the workload can
|
|
|
|
* settle down.
|
|
|
|
* A task that migrated to a second choice node will be better off
|
|
|
|
* trying for a better one later. Do not set the preferred node here.
|
|
|
|
*/
|
2019-07-16 15:20:47 +00:00
|
|
|
if (ng) {
|
2014-06-23 15:41:34 +00:00
|
|
|
if (env.best_cpu == -1)
|
|
|
|
nid = env.src_nid;
|
|
|
|
else
|
2018-06-20 17:02:45 +00:00
|
|
|
nid = cpu_to_node(env.best_cpu);
|
2014-06-23 15:41:34 +00:00
|
|
|
|
2018-06-20 17:02:45 +00:00
|
|
|
if (nid != p->numa_preferred_nid)
|
|
|
|
sched_setnuma(p, nid);
|
2014-06-23 15:41:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* No better CPU than the current one was found. */
|
|
|
|
if (env.best_cpu == -1)
|
|
|
|
return -EAGAIN;
|
2013-10-07 10:29:33 +00:00
|
|
|
|
sched/numa: Stop multiple tasks from moving to the CPU at the same time
Task migration under NUMA balancing can happen in parallel. More than
one task might choose to migrate to the same CPU at the same time. This
can result in:
- During task swap, choosing a task that was not part of the evaluation.
- During task swap, task which just got moved into its preferred node,
moving to a completely different node.
- During task swap, task failing to move to the preferred node, will have
to wait an extra interval for the next migrate opportunity.
- During task movement, multiple task movements can cause load imbalance.
This problem is more likely if there are more cores per node or more
nodes in the system.
Use a per run-queue variable to check if NUMA-balance is active on the
run-queue.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200194 203353 1.57797
1 311331 328205 5.41995
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 197654 214384 8.46429
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 192605 188553 -2.10379
1 213402 196273 -8.02664
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 52227.1 57581.2 10.2516
1 102529 103468 0.915838
There is a regression on power 9 box. If we look at the details,
that box has a sudden jump in cache-misses with this patch.
All other parameters seem to be pointing towards NUMA
consolidation.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,345,784 13,941,377
migrations 1,127,820 1,157,323
faults 374,736 382,175
cache-misses 55,132,054,603 54,993,823,500
sched:sched_move_numa 1,923 2,005
sched:sched_stick_numa 52 14
sched:sched_swap_numa 595 529
migrate:mm_migrate_pages 1,932 1,573
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 60605 67099
numa_hint_faults_local 51804 58456
numa_hit 239945 240416
numa_huge_pte_updates 14 18
numa_interleave 60 65
numa_local 239865 240339
numa_other 80 77
numa_pages_migrated 1931 1574
numa_pte_updates 67823 77182
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,016,467 3,176,453
migrations 37,326 30,238
faults 115,342 87,869
cache-misses 11,692,155,554 12,544,479,391
sched:sched_move_numa 965 23
sched:sched_stick_numa 8 0
sched:sched_swap_numa 35 6
migrate:mm_migrate_pages 1,168 10
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 16286 236
numa_hint_faults_local 11863 201
numa_hit 112482 72293
numa_huge_pte_updates 33 0
numa_interleave 20 26
numa_local 112419 72233
numa_other 63 60
numa_pages_migrated 1144 8
numa_pte_updates 32859 0
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,629,724 8,478,820
migrations 221,052 171,323
faults 308,661 307,499
cache-misses 135,574,913 240,353,599
sched:sched_move_numa 147 214
sched:sched_stick_numa 0 0
sched:sched_swap_numa 2 4
migrate:mm_migrate_pages 64 89
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11481 5301
numa_hint_faults_local 10968 4745
numa_hit 89773 92943
numa_huge_pte_updates 0 0
numa_interleave 1116 899
numa_local 89220 92345
numa_other 553 598
numa_pages_migrated 62 88
numa_pte_updates 11694 5505
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,272,887 2,066,172
migrations 12,206 11,076
faults 163,704 149,544
cache-misses 4,801,186 10,398,067
sched:sched_move_numa 44 43
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 17 6
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 2261 3552
numa_hint_faults_local 1993 3347
numa_hit 25726 25611
numa_huge_pte_updates 0 0
numa_interleave 239 213
numa_local 25498 25583
numa_other 228 28
numa_pages_migrated 17 6
numa_pte_updates 2266 3535
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 117,980,962 99,358,136
migrations 3,950,220 4,041,607
faults 736,979 749,653
cache-misses 224,976,072,879 225,562,543,251
sched:sched_move_numa 504 771
sched:sched_stick_numa 50 14
sched:sched_swap_numa 239 204
migrate:mm_migrate_pages 1,260 1,180
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 18293 27409
numa_hint_faults_local 11969 20677
numa_hit 240854 239988
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 240851 239983
numa_other 3 5
numa_pages_migrated 1190 1016
numa_pte_updates 18106 27916
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 61,053,158 60,899,307
migrations 551,586 544,668
faults 244,174 270,834
cache-misses 74,326,766,973 74,543,455,635
sched:sched_move_numa 344 735
sched:sched_stick_numa 24 25
sched:sched_swap_numa 140 174
migrate:mm_migrate_pages 568 816
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 6461 11059
numa_hint_faults_local 2283 4733
numa_hit 35661 41384
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 35661 41383
numa_other 0 1
numa_pages_migrated 568 815
numa_pte_updates 6518 11323
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Rik van Riel <riel@surriel.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-2-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:56 +00:00
|
|
|
best_rq = cpu_rq(env.best_cpu);
|
2013-10-07 10:29:17 +00:00
|
|
|
if (env.best_task == NULL) {
|
2014-01-21 23:51:03 +00:00
|
|
|
ret = migrate_task_to(p, env.best_cpu);
|
sched/numa: Stop multiple tasks from moving to the CPU at the same time
Task migration under NUMA balancing can happen in parallel. More than
one task might choose to migrate to the same CPU at the same time. This
can result in:
- During task swap, choosing a task that was not part of the evaluation.
- During task swap, task which just got moved into its preferred node,
moving to a completely different node.
- During task swap, task failing to move to the preferred node, will have
to wait an extra interval for the next migrate opportunity.
- During task movement, multiple task movements can cause load imbalance.
This problem is more likely if there are more cores per node or more
nodes in the system.
Use a per run-queue variable to check if NUMA-balance is active on the
run-queue.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200194 203353 1.57797
1 311331 328205 5.41995
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 197654 214384 8.46429
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 192605 188553 -2.10379
1 213402 196273 -8.02664
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 52227.1 57581.2 10.2516
1 102529 103468 0.915838
There is a regression on power 9 box. If we look at the details,
that box has a sudden jump in cache-misses with this patch.
All other parameters seem to be pointing towards NUMA
consolidation.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,345,784 13,941,377
migrations 1,127,820 1,157,323
faults 374,736 382,175
cache-misses 55,132,054,603 54,993,823,500
sched:sched_move_numa 1,923 2,005
sched:sched_stick_numa 52 14
sched:sched_swap_numa 595 529
migrate:mm_migrate_pages 1,932 1,573
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 60605 67099
numa_hint_faults_local 51804 58456
numa_hit 239945 240416
numa_huge_pte_updates 14 18
numa_interleave 60 65
numa_local 239865 240339
numa_other 80 77
numa_pages_migrated 1931 1574
numa_pte_updates 67823 77182
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,016,467 3,176,453
migrations 37,326 30,238
faults 115,342 87,869
cache-misses 11,692,155,554 12,544,479,391
sched:sched_move_numa 965 23
sched:sched_stick_numa 8 0
sched:sched_swap_numa 35 6
migrate:mm_migrate_pages 1,168 10
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 16286 236
numa_hint_faults_local 11863 201
numa_hit 112482 72293
numa_huge_pte_updates 33 0
numa_interleave 20 26
numa_local 112419 72233
numa_other 63 60
numa_pages_migrated 1144 8
numa_pte_updates 32859 0
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,629,724 8,478,820
migrations 221,052 171,323
faults 308,661 307,499
cache-misses 135,574,913 240,353,599
sched:sched_move_numa 147 214
sched:sched_stick_numa 0 0
sched:sched_swap_numa 2 4
migrate:mm_migrate_pages 64 89
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11481 5301
numa_hint_faults_local 10968 4745
numa_hit 89773 92943
numa_huge_pte_updates 0 0
numa_interleave 1116 899
numa_local 89220 92345
numa_other 553 598
numa_pages_migrated 62 88
numa_pte_updates 11694 5505
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,272,887 2,066,172
migrations 12,206 11,076
faults 163,704 149,544
cache-misses 4,801,186 10,398,067
sched:sched_move_numa 44 43
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 17 6
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 2261 3552
numa_hint_faults_local 1993 3347
numa_hit 25726 25611
numa_huge_pte_updates 0 0
numa_interleave 239 213
numa_local 25498 25583
numa_other 228 28
numa_pages_migrated 17 6
numa_pte_updates 2266 3535
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 117,980,962 99,358,136
migrations 3,950,220 4,041,607
faults 736,979 749,653
cache-misses 224,976,072,879 225,562,543,251
sched:sched_move_numa 504 771
sched:sched_stick_numa 50 14
sched:sched_swap_numa 239 204
migrate:mm_migrate_pages 1,260 1,180
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 18293 27409
numa_hint_faults_local 11969 20677
numa_hit 240854 239988
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 240851 239983
numa_other 3 5
numa_pages_migrated 1190 1016
numa_pte_updates 18106 27916
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 61,053,158 60,899,307
migrations 551,586 544,668
faults 244,174 270,834
cache-misses 74,326,766,973 74,543,455,635
sched:sched_move_numa 344 735
sched:sched_stick_numa 24 25
sched:sched_swap_numa 140 174
migrate:mm_migrate_pages 568 816
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 6461 11059
numa_hint_faults_local 2283 4733
numa_hit 35661 41384
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 35661 41383
numa_other 0 1
numa_pages_migrated 568 815
numa_pte_updates 6518 11323
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Rik van Riel <riel@surriel.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-2-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:56 +00:00
|
|
|
WRITE_ONCE(best_rq->numa_migrate_on, 0);
|
2014-01-21 23:51:03 +00:00
|
|
|
if (ret != 0)
|
|
|
|
trace_sched_stick_numa(p, env.src_cpu, env.best_cpu);
|
2013-10-07 10:29:17 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-06-20 17:02:50 +00:00
|
|
|
ret = migrate_swap(p, env.best_task, env.best_cpu, env.src_cpu);
|
sched/numa: Stop multiple tasks from moving to the CPU at the same time
Task migration under NUMA balancing can happen in parallel. More than
one task might choose to migrate to the same CPU at the same time. This
can result in:
- During task swap, choosing a task that was not part of the evaluation.
- During task swap, task which just got moved into its preferred node,
moving to a completely different node.
- During task swap, task failing to move to the preferred node, will have
to wait an extra interval for the next migrate opportunity.
- During task movement, multiple task movements can cause load imbalance.
This problem is more likely if there are more cores per node or more
nodes in the system.
Use a per run-queue variable to check if NUMA-balance is active on the
run-queue.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200194 203353 1.57797
1 311331 328205 5.41995
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 197654 214384 8.46429
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 192605 188553 -2.10379
1 213402 196273 -8.02664
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 52227.1 57581.2 10.2516
1 102529 103468 0.915838
There is a regression on power 9 box. If we look at the details,
that box has a sudden jump in cache-misses with this patch.
All other parameters seem to be pointing towards NUMA
consolidation.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,345,784 13,941,377
migrations 1,127,820 1,157,323
faults 374,736 382,175
cache-misses 55,132,054,603 54,993,823,500
sched:sched_move_numa 1,923 2,005
sched:sched_stick_numa 52 14
sched:sched_swap_numa 595 529
migrate:mm_migrate_pages 1,932 1,573
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 60605 67099
numa_hint_faults_local 51804 58456
numa_hit 239945 240416
numa_huge_pte_updates 14 18
numa_interleave 60 65
numa_local 239865 240339
numa_other 80 77
numa_pages_migrated 1931 1574
numa_pte_updates 67823 77182
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,016,467 3,176,453
migrations 37,326 30,238
faults 115,342 87,869
cache-misses 11,692,155,554 12,544,479,391
sched:sched_move_numa 965 23
sched:sched_stick_numa 8 0
sched:sched_swap_numa 35 6
migrate:mm_migrate_pages 1,168 10
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 16286 236
numa_hint_faults_local 11863 201
numa_hit 112482 72293
numa_huge_pte_updates 33 0
numa_interleave 20 26
numa_local 112419 72233
numa_other 63 60
numa_pages_migrated 1144 8
numa_pte_updates 32859 0
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,629,724 8,478,820
migrations 221,052 171,323
faults 308,661 307,499
cache-misses 135,574,913 240,353,599
sched:sched_move_numa 147 214
sched:sched_stick_numa 0 0
sched:sched_swap_numa 2 4
migrate:mm_migrate_pages 64 89
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11481 5301
numa_hint_faults_local 10968 4745
numa_hit 89773 92943
numa_huge_pte_updates 0 0
numa_interleave 1116 899
numa_local 89220 92345
numa_other 553 598
numa_pages_migrated 62 88
numa_pte_updates 11694 5505
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,272,887 2,066,172
migrations 12,206 11,076
faults 163,704 149,544
cache-misses 4,801,186 10,398,067
sched:sched_move_numa 44 43
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 17 6
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 2261 3552
numa_hint_faults_local 1993 3347
numa_hit 25726 25611
numa_huge_pte_updates 0 0
numa_interleave 239 213
numa_local 25498 25583
numa_other 228 28
numa_pages_migrated 17 6
numa_pte_updates 2266 3535
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 117,980,962 99,358,136
migrations 3,950,220 4,041,607
faults 736,979 749,653
cache-misses 224,976,072,879 225,562,543,251
sched:sched_move_numa 504 771
sched:sched_stick_numa 50 14
sched:sched_swap_numa 239 204
migrate:mm_migrate_pages 1,260 1,180
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 18293 27409
numa_hint_faults_local 11969 20677
numa_hit 240854 239988
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 240851 239983
numa_other 3 5
numa_pages_migrated 1190 1016
numa_pte_updates 18106 27916
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 61,053,158 60,899,307
migrations 551,586 544,668
faults 244,174 270,834
cache-misses 74,326,766,973 74,543,455,635
sched:sched_move_numa 344 735
sched:sched_stick_numa 24 25
sched:sched_swap_numa 140 174
migrate:mm_migrate_pages 568 816
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 6461 11059
numa_hint_faults_local 2283 4733
numa_hit 35661 41384
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 35661 41383
numa_other 0 1
numa_pages_migrated 568 815
numa_pte_updates 6518 11323
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Rik van Riel <riel@surriel.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-2-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:56 +00:00
|
|
|
WRITE_ONCE(best_rq->numa_migrate_on, 0);
|
2018-06-20 17:02:50 +00:00
|
|
|
|
2014-01-21 23:51:03 +00:00
|
|
|
if (ret != 0)
|
|
|
|
trace_sched_stick_numa(p, env.src_cpu, task_cpu(env.best_task));
|
2013-10-07 10:29:17 +00:00
|
|
|
put_task_struct(env.best_task);
|
|
|
|
return ret;
|
2013-10-07 10:29:02 +00:00
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:11 +00:00
|
|
|
/* Attempt to migrate a task to a CPU on the preferred node. */
|
|
|
|
static void numa_migrate_preferred(struct task_struct *p)
|
|
|
|
{
|
2014-04-11 17:00:28 +00:00
|
|
|
unsigned long interval = HZ;
|
|
|
|
|
2013-10-07 10:29:41 +00:00
|
|
|
/* This task has no NUMA fault statistics yet */
|
2019-03-05 23:42:58 +00:00
|
|
|
if (unlikely(p->numa_preferred_nid == NUMA_NO_NODE || !p->numa_faults))
|
2013-10-07 10:29:11 +00:00
|
|
|
return;
|
|
|
|
|
2013-10-07 10:29:41 +00:00
|
|
|
/* Periodically retry migrating the task to the preferred node */
|
2014-04-11 17:00:28 +00:00
|
|
|
interval = min(interval, msecs_to_jiffies(p->numa_scan_period) / 16);
|
Revert "sched/numa: Delay retrying placement for automatic NUMA balance after wake_affine()"
This reverts commit 7347fc87dfe6b7315e74310ee1243dc222c68086.
Srikar Dronamra pointed out that while the commit in question did show
a performance improvement on ppc64, it did so at the cost of disabling
active CPU migration by automatic NUMA balancing which was not the intent.
The issue was that a serious flaw in the logic failed to ever active balance
if SD_WAKE_AFFINE was disabled on scheduler domains. Even when it's enabled,
the logic is still bizarre and against the original intent.
Investigation showed that fixing the patch in either the way he suggested,
using the correct comparison for jiffies values or introducing a new
numa_migrate_deferred variable in task_struct all perform similarly to a
revert with a mix of gains and losses depending on the workload, machine
and socket count.
The original intent of the commit was to handle a problem whereby
wake_affine, idle balancing and automatic NUMA balancing disagree on the
appropriate placement for a task. This was particularly true for cases where
a single task was a massive waker of tasks but where wake_wide logic did
not apply. This was particularly noticeable when a futex (a barrier) woke
all worker threads and tried pulling the wakees to the waker nodes. In that
specific case, it could be handled by tuning MPI or openMP appropriately,
but the behavior is not illogical and was worth attempting to fix. However,
the approach was wrong. Given that we're at rc4 and a fix is not obvious,
it's better to play safe, revert this commit and retry later.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: efault@gmx.de
Cc: ggherdovich@suse.cz
Cc: hpa@zytor.com
Cc: matt@codeblueprint.co.uk
Cc: mpe@ellerman.id.au
Link: http://lkml.kernel.org/r/20180509163115.6fnnyeg4vdm2ct4v@techsingularity.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-05-09 16:31:15 +00:00
|
|
|
p->numa_migrate_retry = jiffies + interval;
|
2013-10-07 10:29:41 +00:00
|
|
|
|
|
|
|
/* Success if task is already running on preferred CPU */
|
2013-12-12 07:23:24 +00:00
|
|
|
if (task_node(p) == p->numa_preferred_nid)
|
2013-10-07 10:29:11 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
/* Otherwise, try migrate to a CPU on the preferred node */
|
2013-10-07 10:29:41 +00:00
|
|
|
task_numa_migrate(p);
|
2013-10-07 10:29:11 +00:00
|
|
|
}
|
|
|
|
|
2014-01-27 22:03:43 +00:00
|
|
|
/*
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
* Find out how many nodes on the workload is actively running on. Do this by
|
2014-01-27 22:03:43 +00:00
|
|
|
* tracking the nodes from which NUMA hinting faults are triggered. This can
|
|
|
|
* be different from the set of nodes where the workload's memory is currently
|
|
|
|
* located.
|
|
|
|
*/
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
static void numa_group_count_active_nodes(struct numa_group *numa_group)
|
2014-01-27 22:03:43 +00:00
|
|
|
{
|
|
|
|
unsigned long faults, max_faults = 0;
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
int nid, active_nodes = 0;
|
2014-01-27 22:03:43 +00:00
|
|
|
|
|
|
|
for_each_online_node(nid) {
|
|
|
|
faults = group_faults_cpu(numa_group, nid);
|
|
|
|
if (faults > max_faults)
|
|
|
|
max_faults = faults;
|
|
|
|
}
|
|
|
|
|
|
|
|
for_each_online_node(nid) {
|
|
|
|
faults = group_faults_cpu(numa_group, nid);
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
if (faults * ACTIVE_NODE_FRACTION > max_faults)
|
|
|
|
active_nodes++;
|
2014-01-27 22:03:43 +00:00
|
|
|
}
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
|
|
|
|
numa_group->max_faults_cpu = max_faults;
|
|
|
|
numa_group->active_nodes = active_nodes;
|
2014-01-27 22:03:43 +00:00
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:36 +00:00
|
|
|
/*
|
|
|
|
* When adapting the scan rate, the period is divided into NUMA_PERIOD_SLOTS
|
|
|
|
* increments. The more local the fault statistics are, the higher the scan
|
2014-06-23 15:41:35 +00:00
|
|
|
* period will be for the next scan window. If local/(local+remote) ratio is
|
|
|
|
* below NUMA_PERIOD_THRESHOLD (where range of ratio is 1..NUMA_PERIOD_SLOTS)
|
|
|
|
* the scan period will decrease. Aim for 70% local accesses.
|
2013-10-07 10:29:36 +00:00
|
|
|
*/
|
|
|
|
#define NUMA_PERIOD_SLOTS 10
|
2014-06-23 15:41:35 +00:00
|
|
|
#define NUMA_PERIOD_THRESHOLD 7
|
2013-10-07 10:29:36 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Increase the scan period (slow down scanning) if the majority of
|
|
|
|
* our memory is already on our local node, or if the majority of
|
|
|
|
* the page accesses are shared with other processes.
|
|
|
|
* Otherwise, decrease the scan period.
|
|
|
|
*/
|
|
|
|
static void update_task_scan_period(struct task_struct *p,
|
|
|
|
unsigned long shared, unsigned long private)
|
|
|
|
{
|
|
|
|
unsigned int period_slot;
|
2017-07-31 19:28:46 +00:00
|
|
|
int lr_ratio, ps_ratio;
|
2013-10-07 10:29:36 +00:00
|
|
|
int diff;
|
|
|
|
|
|
|
|
unsigned long remote = p->numa_faults_locality[0];
|
|
|
|
unsigned long local = p->numa_faults_locality[1];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there were no record hinting faults then either the task is
|
|
|
|
* completely idle or all activity is areas that are not of interest
|
2015-03-25 22:55:42 +00:00
|
|
|
* to automatic numa balancing. Related to that, if there were failed
|
|
|
|
* migration then it implies we are migrating too quickly or the local
|
|
|
|
* node is overloaded. In either case, scan slower
|
2013-10-07 10:29:36 +00:00
|
|
|
*/
|
2015-03-25 22:55:42 +00:00
|
|
|
if (local + shared == 0 || p->numa_faults_locality[2]) {
|
2013-10-07 10:29:36 +00:00
|
|
|
p->numa_scan_period = min(p->numa_scan_period_max,
|
|
|
|
p->numa_scan_period << 1);
|
|
|
|
|
|
|
|
p->mm->numa_next_scan = jiffies +
|
|
|
|
msecs_to_jiffies(p->numa_scan_period);
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prepare to scale scan period relative to the current period.
|
|
|
|
* == NUMA_PERIOD_THRESHOLD scan period stays the same
|
|
|
|
* < NUMA_PERIOD_THRESHOLD scan period decreases (scan faster)
|
|
|
|
* >= NUMA_PERIOD_THRESHOLD scan period increases (scan slower)
|
|
|
|
*/
|
|
|
|
period_slot = DIV_ROUND_UP(p->numa_scan_period, NUMA_PERIOD_SLOTS);
|
2017-07-31 19:28:46 +00:00
|
|
|
lr_ratio = (local * NUMA_PERIOD_SLOTS) / (local + remote);
|
|
|
|
ps_ratio = (private * NUMA_PERIOD_SLOTS) / (private + shared);
|
|
|
|
|
|
|
|
if (ps_ratio >= NUMA_PERIOD_THRESHOLD) {
|
|
|
|
/*
|
|
|
|
* Most memory accesses are local. There is no need to
|
|
|
|
* do fast NUMA scanning, since memory is already local.
|
|
|
|
*/
|
|
|
|
int slot = ps_ratio - NUMA_PERIOD_THRESHOLD;
|
|
|
|
if (!slot)
|
|
|
|
slot = 1;
|
|
|
|
diff = slot * period_slot;
|
|
|
|
} else if (lr_ratio >= NUMA_PERIOD_THRESHOLD) {
|
|
|
|
/*
|
|
|
|
* Most memory accesses are shared with other tasks.
|
|
|
|
* There is no point in continuing fast NUMA scanning,
|
|
|
|
* since other tasks may just move the memory elsewhere.
|
|
|
|
*/
|
|
|
|
int slot = lr_ratio - NUMA_PERIOD_THRESHOLD;
|
2013-10-07 10:29:36 +00:00
|
|
|
if (!slot)
|
|
|
|
slot = 1;
|
|
|
|
diff = slot * period_slot;
|
|
|
|
} else {
|
|
|
|
/*
|
2017-07-31 19:28:46 +00:00
|
|
|
* Private memory faults exceed (SLOTS-THRESHOLD)/SLOTS,
|
|
|
|
* yet they are not on the local NUMA node. Speed up
|
|
|
|
* NUMA scanning to get the memory moved over.
|
2013-10-07 10:29:36 +00:00
|
|
|
*/
|
2017-07-31 19:28:46 +00:00
|
|
|
int ratio = max(lr_ratio, ps_ratio);
|
|
|
|
diff = -(NUMA_PERIOD_THRESHOLD - ratio) * period_slot;
|
2013-10-07 10:29:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
p->numa_scan_period = clamp(p->numa_scan_period + diff,
|
|
|
|
task_scan_min(p), task_scan_max(p));
|
|
|
|
memset(p->numa_faults_locality, 0, sizeof(p->numa_faults_locality));
|
|
|
|
}
|
|
|
|
|
sched/numa: Normalize faults_cpu stats and weigh by CPU use
Tracing the code that decides the active nodes has made it abundantly clear
that the naive implementation of the faults_from code has issues.
Specifically, the garbage collector in some workloads will access orders
of magnitudes more memory than the threads that do all the active work.
This resulted in the node with the garbage collector being marked the only
active node in the group.
This issue is avoided if we weigh the statistics by CPU use of each task in
the numa group, instead of by how many faults each thread has occurred.
To achieve this, we normalize the number of faults to the fraction of faults
that occurred on each node, and then multiply that fraction by the fraction
of CPU time the task has used since the last time task_numa_placement was
invoked.
This way the nodes in the active node mask will be the ones where the tasks
from the numa group are most actively running, and the influence of eg. the
garbage collector and other do-little threads is properly minimized.
On a 4 node system, using CPU use statistics calculated over a longer interval
results in about 1% fewer page migrations with two 32-warehouse specjbb runs
on a 4 node system, and about 5% fewer page migrations, as well as 1% better
throughput, with two 8-warehouse specjbb runs, as compared with the shorter
term statistics kept by the scheduler.
Signed-off-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Chegu Vinod <chegu_vinod@hp.com>
Link: http://lkml.kernel.org/r/1390860228-21539-7-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-01-27 22:03:45 +00:00
|
|
|
/*
|
|
|
|
* Get the fraction of time the task has been running since the last
|
|
|
|
* NUMA placement cycle. The scheduler keeps similar statistics, but
|
|
|
|
* decays those on a 32ms period, which is orders of magnitude off
|
|
|
|
* from the dozens-of-seconds NUMA balancing period. Use the scheduler
|
|
|
|
* stats only if the task is so new there are no NUMA statistics yet.
|
|
|
|
*/
|
|
|
|
static u64 numa_get_avg_runtime(struct task_struct *p, u64 *period)
|
|
|
|
{
|
|
|
|
u64 runtime, delta, now;
|
|
|
|
/* Use the start of this time slice to avoid calculations. */
|
|
|
|
now = p->se.exec_start;
|
|
|
|
runtime = p->se.sum_exec_runtime;
|
|
|
|
|
|
|
|
if (p->last_task_numa_placement) {
|
|
|
|
delta = runtime - p->last_sum_exec_runtime;
|
|
|
|
*period = now - p->last_task_numa_placement;
|
2019-04-20 08:34:16 +00:00
|
|
|
|
|
|
|
/* Avoid time going backwards, prevent potential divide error: */
|
|
|
|
if (unlikely((s64)*period < 0))
|
|
|
|
*period = 0;
|
sched/numa: Normalize faults_cpu stats and weigh by CPU use
Tracing the code that decides the active nodes has made it abundantly clear
that the naive implementation of the faults_from code has issues.
Specifically, the garbage collector in some workloads will access orders
of magnitudes more memory than the threads that do all the active work.
This resulted in the node with the garbage collector being marked the only
active node in the group.
This issue is avoided if we weigh the statistics by CPU use of each task in
the numa group, instead of by how many faults each thread has occurred.
To achieve this, we normalize the number of faults to the fraction of faults
that occurred on each node, and then multiply that fraction by the fraction
of CPU time the task has used since the last time task_numa_placement was
invoked.
This way the nodes in the active node mask will be the ones where the tasks
from the numa group are most actively running, and the influence of eg. the
garbage collector and other do-little threads is properly minimized.
On a 4 node system, using CPU use statistics calculated over a longer interval
results in about 1% fewer page migrations with two 32-warehouse specjbb runs
on a 4 node system, and about 5% fewer page migrations, as well as 1% better
throughput, with two 8-warehouse specjbb runs, as compared with the shorter
term statistics kept by the scheduler.
Signed-off-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Chegu Vinod <chegu_vinod@hp.com>
Link: http://lkml.kernel.org/r/1390860228-21539-7-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-01-27 22:03:45 +00:00
|
|
|
} else {
|
2017-05-06 14:42:08 +00:00
|
|
|
delta = p->se.avg.load_sum;
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
*period = LOAD_AVG_MAX;
|
sched/numa: Normalize faults_cpu stats and weigh by CPU use
Tracing the code that decides the active nodes has made it abundantly clear
that the naive implementation of the faults_from code has issues.
Specifically, the garbage collector in some workloads will access orders
of magnitudes more memory than the threads that do all the active work.
This resulted in the node with the garbage collector being marked the only
active node in the group.
This issue is avoided if we weigh the statistics by CPU use of each task in
the numa group, instead of by how many faults each thread has occurred.
To achieve this, we normalize the number of faults to the fraction of faults
that occurred on each node, and then multiply that fraction by the fraction
of CPU time the task has used since the last time task_numa_placement was
invoked.
This way the nodes in the active node mask will be the ones where the tasks
from the numa group are most actively running, and the influence of eg. the
garbage collector and other do-little threads is properly minimized.
On a 4 node system, using CPU use statistics calculated over a longer interval
results in about 1% fewer page migrations with two 32-warehouse specjbb runs
on a 4 node system, and about 5% fewer page migrations, as well as 1% better
throughput, with two 8-warehouse specjbb runs, as compared with the shorter
term statistics kept by the scheduler.
Signed-off-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Chegu Vinod <chegu_vinod@hp.com>
Link: http://lkml.kernel.org/r/1390860228-21539-7-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-01-27 22:03:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
p->last_sum_exec_runtime = runtime;
|
|
|
|
p->last_task_numa_placement = now;
|
|
|
|
|
|
|
|
return delta;
|
|
|
|
}
|
|
|
|
|
2014-10-17 07:29:53 +00:00
|
|
|
/*
|
|
|
|
* Determine the preferred nid for a task in a numa_group. This needs to
|
|
|
|
* be done in a way that produces consistent results with group_weight,
|
|
|
|
* otherwise workloads might not converge.
|
|
|
|
*/
|
|
|
|
static int preferred_group_nid(struct task_struct *p, int nid)
|
|
|
|
{
|
|
|
|
nodemask_t nodes;
|
|
|
|
int dist;
|
|
|
|
|
|
|
|
/* Direct connections between all NUMA nodes. */
|
|
|
|
if (sched_numa_topology_type == NUMA_DIRECT)
|
|
|
|
return nid;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* On a system with glueless mesh NUMA topology, group_weight
|
|
|
|
* scores nodes according to the number of NUMA hinting faults on
|
|
|
|
* both the node itself, and on nearby nodes.
|
|
|
|
*/
|
|
|
|
if (sched_numa_topology_type == NUMA_GLUELESS_MESH) {
|
|
|
|
unsigned long score, max_score = 0;
|
|
|
|
int node, max_node = nid;
|
|
|
|
|
|
|
|
dist = sched_max_numa_distance;
|
|
|
|
|
|
|
|
for_each_online_node(node) {
|
|
|
|
score = group_weight(p, node, dist);
|
|
|
|
if (score > max_score) {
|
|
|
|
max_score = score;
|
|
|
|
max_node = node;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return max_node;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Finding the preferred nid in a system with NUMA backplane
|
|
|
|
* interconnect topology is more involved. The goal is to locate
|
|
|
|
* tasks from numa_groups near each other in the system, and
|
|
|
|
* untangle workloads from different sides of the system. This requires
|
|
|
|
* searching down the hierarchy of node groups, recursively searching
|
|
|
|
* inside the highest scoring group of nodes. The nodemask tricks
|
|
|
|
* keep the complexity of the search down.
|
|
|
|
*/
|
|
|
|
nodes = node_online_map;
|
|
|
|
for (dist = sched_max_numa_distance; dist > LOCAL_DISTANCE; dist--) {
|
|
|
|
unsigned long max_faults = 0;
|
sched/fair: Avoid using uninitialized variable in preferred_group_nid()
At least some gcc versions - validly afaict - warn about potentially
using max_group uninitialized: There's no way the compiler can prove
that the body of the conditional where it and max_faults get set/
updated gets executed; in fact, without knowing all the details of
other scheduler code, I can't prove this either.
Generally the necessary change would appear to be to clear max_group
prior to entering the inner loop, and break out of the outer loop when
it ends up being all clear after the inner one. This, however, seems
inefficient, and afaict the same effect can be achieved by exiting the
outer loop when max_faults is still zero after the inner loop.
[ mingo: changed the solution to zero initialization: uninitialized_var()
needs to die, as it's an actively dangerous construct: if in the future
a known-proven-good piece of code is changed to have a true, buggy
uninitialized variable, the compiler warning is then supressed...
The better long term solution is to clean up the code flow, so that
even simple minded compilers (and humans!) are able to read it without
getting a headache. ]
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/54C2139202000078000588F7@mail.emea.novell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-01-23 08:25:38 +00:00
|
|
|
nodemask_t max_group = NODE_MASK_NONE;
|
2014-10-17 07:29:53 +00:00
|
|
|
int a, b;
|
|
|
|
|
|
|
|
/* Are there nodes at this distance from each other? */
|
|
|
|
if (!find_numa_distance(dist))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
for_each_node_mask(a, nodes) {
|
|
|
|
unsigned long faults = 0;
|
|
|
|
nodemask_t this_group;
|
|
|
|
nodes_clear(this_group);
|
|
|
|
|
|
|
|
/* Sum group's NUMA faults; includes a==b case. */
|
|
|
|
for_each_node_mask(b, nodes) {
|
|
|
|
if (node_distance(a, b) < dist) {
|
|
|
|
faults += group_faults(p, b);
|
|
|
|
node_set(b, this_group);
|
|
|
|
node_clear(b, nodes);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Remember the top group. */
|
|
|
|
if (faults > max_faults) {
|
|
|
|
max_faults = faults;
|
|
|
|
max_group = this_group;
|
|
|
|
/*
|
|
|
|
* subtle: at the smallest distance there is
|
|
|
|
* just one node left in each "group", the
|
|
|
|
* winner is the preferred nid.
|
|
|
|
*/
|
|
|
|
nid = a;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* Next round, evaluate the nodes within max_group. */
|
2015-02-09 11:30:00 +00:00
|
|
|
if (!max_faults)
|
|
|
|
break;
|
2014-10-17 07:29:53 +00:00
|
|
|
nodes = max_group;
|
|
|
|
}
|
|
|
|
return nid;
|
|
|
|
}
|
|
|
|
|
2012-10-25 12:16:43 +00:00
|
|
|
static void task_numa_placement(struct task_struct *p)
|
|
|
|
{
|
2019-03-05 23:42:58 +00:00
|
|
|
int seq, nid, max_nid = NUMA_NO_NODE;
|
2018-06-20 17:02:46 +00:00
|
|
|
unsigned long max_faults = 0;
|
2013-10-07 10:29:36 +00:00
|
|
|
unsigned long fault_types[2] = { 0, 0 };
|
sched/numa: Normalize faults_cpu stats and weigh by CPU use
Tracing the code that decides the active nodes has made it abundantly clear
that the naive implementation of the faults_from code has issues.
Specifically, the garbage collector in some workloads will access orders
of magnitudes more memory than the threads that do all the active work.
This resulted in the node with the garbage collector being marked the only
active node in the group.
This issue is avoided if we weigh the statistics by CPU use of each task in
the numa group, instead of by how many faults each thread has occurred.
To achieve this, we normalize the number of faults to the fraction of faults
that occurred on each node, and then multiply that fraction by the fraction
of CPU time the task has used since the last time task_numa_placement was
invoked.
This way the nodes in the active node mask will be the ones where the tasks
from the numa group are most actively running, and the influence of eg. the
garbage collector and other do-little threads is properly minimized.
On a 4 node system, using CPU use statistics calculated over a longer interval
results in about 1% fewer page migrations with two 32-warehouse specjbb runs
on a 4 node system, and about 5% fewer page migrations, as well as 1% better
throughput, with two 8-warehouse specjbb runs, as compared with the shorter
term statistics kept by the scheduler.
Signed-off-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Chegu Vinod <chegu_vinod@hp.com>
Link: http://lkml.kernel.org/r/1390860228-21539-7-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-01-27 22:03:45 +00:00
|
|
|
unsigned long total_faults;
|
|
|
|
u64 runtime, period;
|
2013-10-07 10:29:29 +00:00
|
|
|
spinlock_t *group_lock = NULL;
|
2019-07-16 15:20:47 +00:00
|
|
|
struct numa_group *ng;
|
2012-10-25 12:16:43 +00:00
|
|
|
|
2015-05-01 00:28:14 +00:00
|
|
|
/*
|
|
|
|
* The p->mm->numa_scan_seq field gets updated without
|
|
|
|
* exclusive access. Use READ_ONCE() here to ensure
|
|
|
|
* that the field is read in a single access:
|
|
|
|
*/
|
2015-04-28 20:00:20 +00:00
|
|
|
seq = READ_ONCE(p->mm->numa_scan_seq);
|
2012-10-25 12:16:43 +00:00
|
|
|
if (p->numa_scan_seq == seq)
|
|
|
|
return;
|
|
|
|
p->numa_scan_seq = seq;
|
2013-10-07 10:28:55 +00:00
|
|
|
p->numa_scan_period_max = task_scan_max(p);
|
2012-10-25 12:16:43 +00:00
|
|
|
|
sched/numa: Normalize faults_cpu stats and weigh by CPU use
Tracing the code that decides the active nodes has made it abundantly clear
that the naive implementation of the faults_from code has issues.
Specifically, the garbage collector in some workloads will access orders
of magnitudes more memory than the threads that do all the active work.
This resulted in the node with the garbage collector being marked the only
active node in the group.
This issue is avoided if we weigh the statistics by CPU use of each task in
the numa group, instead of by how many faults each thread has occurred.
To achieve this, we normalize the number of faults to the fraction of faults
that occurred on each node, and then multiply that fraction by the fraction
of CPU time the task has used since the last time task_numa_placement was
invoked.
This way the nodes in the active node mask will be the ones where the tasks
from the numa group are most actively running, and the influence of eg. the
garbage collector and other do-little threads is properly minimized.
On a 4 node system, using CPU use statistics calculated over a longer interval
results in about 1% fewer page migrations with two 32-warehouse specjbb runs
on a 4 node system, and about 5% fewer page migrations, as well as 1% better
throughput, with two 8-warehouse specjbb runs, as compared with the shorter
term statistics kept by the scheduler.
Signed-off-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Chegu Vinod <chegu_vinod@hp.com>
Link: http://lkml.kernel.org/r/1390860228-21539-7-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-01-27 22:03:45 +00:00
|
|
|
total_faults = p->numa_faults_locality[0] +
|
|
|
|
p->numa_faults_locality[1];
|
|
|
|
runtime = numa_get_avg_runtime(p, &period);
|
|
|
|
|
2013-10-07 10:29:29 +00:00
|
|
|
/* If the task is part of a group prevent parallel updates to group stats */
|
2019-07-16 15:20:47 +00:00
|
|
|
ng = deref_curr_numa_group(p);
|
|
|
|
if (ng) {
|
|
|
|
group_lock = &ng->lock;
|
2014-04-07 08:55:15 +00:00
|
|
|
spin_lock_irq(group_lock);
|
2013-10-07 10:29:29 +00:00
|
|
|
}
|
|
|
|
|
2013-10-07 10:28:58 +00:00
|
|
|
/* Find the node with the highest number of faults */
|
|
|
|
for_each_online_node(nid) {
|
2014-10-31 00:13:31 +00:00
|
|
|
/* Keep track of the offsets in numa_faults array */
|
|
|
|
int mem_idx, membuf_idx, cpu_idx, cpubuf_idx;
|
2013-10-07 10:29:27 +00:00
|
|
|
unsigned long faults = 0, group_faults = 0;
|
2014-10-31 00:13:31 +00:00
|
|
|
int priv;
|
2013-10-07 10:28:59 +00:00
|
|
|
|
2014-01-27 22:03:48 +00:00
|
|
|
for (priv = 0; priv < NR_NUMA_HINT_FAULT_TYPES; priv++) {
|
sched/numa: Normalize faults_cpu stats and weigh by CPU use
Tracing the code that decides the active nodes has made it abundantly clear
that the naive implementation of the faults_from code has issues.
Specifically, the garbage collector in some workloads will access orders
of magnitudes more memory than the threads that do all the active work.
This resulted in the node with the garbage collector being marked the only
active node in the group.
This issue is avoided if we weigh the statistics by CPU use of each task in
the numa group, instead of by how many faults each thread has occurred.
To achieve this, we normalize the number of faults to the fraction of faults
that occurred on each node, and then multiply that fraction by the fraction
of CPU time the task has used since the last time task_numa_placement was
invoked.
This way the nodes in the active node mask will be the ones where the tasks
from the numa group are most actively running, and the influence of eg. the
garbage collector and other do-little threads is properly minimized.
On a 4 node system, using CPU use statistics calculated over a longer interval
results in about 1% fewer page migrations with two 32-warehouse specjbb runs
on a 4 node system, and about 5% fewer page migrations, as well as 1% better
throughput, with two 8-warehouse specjbb runs, as compared with the shorter
term statistics kept by the scheduler.
Signed-off-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Chegu Vinod <chegu_vinod@hp.com>
Link: http://lkml.kernel.org/r/1390860228-21539-7-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-01-27 22:03:45 +00:00
|
|
|
long diff, f_diff, f_weight;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
2014-10-31 00:13:31 +00:00
|
|
|
mem_idx = task_faults_idx(NUMA_MEM, nid, priv);
|
|
|
|
membuf_idx = task_faults_idx(NUMA_MEMBUF, nid, priv);
|
|
|
|
cpu_idx = task_faults_idx(NUMA_CPU, nid, priv);
|
|
|
|
cpubuf_idx = task_faults_idx(NUMA_CPUBUF, nid, priv);
|
2013-10-07 10:28:59 +00:00
|
|
|
|
2013-10-07 10:29:03 +00:00
|
|
|
/* Decay existing window, copy faults since last scan */
|
2014-10-31 00:13:31 +00:00
|
|
|
diff = p->numa_faults[membuf_idx] - p->numa_faults[mem_idx] / 2;
|
|
|
|
fault_types[priv] += p->numa_faults[membuf_idx];
|
|
|
|
p->numa_faults[membuf_idx] = 0;
|
2013-10-07 10:29:17 +00:00
|
|
|
|
sched/numa: Normalize faults_cpu stats and weigh by CPU use
Tracing the code that decides the active nodes has made it abundantly clear
that the naive implementation of the faults_from code has issues.
Specifically, the garbage collector in some workloads will access orders
of magnitudes more memory than the threads that do all the active work.
This resulted in the node with the garbage collector being marked the only
active node in the group.
This issue is avoided if we weigh the statistics by CPU use of each task in
the numa group, instead of by how many faults each thread has occurred.
To achieve this, we normalize the number of faults to the fraction of faults
that occurred on each node, and then multiply that fraction by the fraction
of CPU time the task has used since the last time task_numa_placement was
invoked.
This way the nodes in the active node mask will be the ones where the tasks
from the numa group are most actively running, and the influence of eg. the
garbage collector and other do-little threads is properly minimized.
On a 4 node system, using CPU use statistics calculated over a longer interval
results in about 1% fewer page migrations with two 32-warehouse specjbb runs
on a 4 node system, and about 5% fewer page migrations, as well as 1% better
throughput, with two 8-warehouse specjbb runs, as compared with the shorter
term statistics kept by the scheduler.
Signed-off-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Chegu Vinod <chegu_vinod@hp.com>
Link: http://lkml.kernel.org/r/1390860228-21539-7-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-01-27 22:03:45 +00:00
|
|
|
/*
|
|
|
|
* Normalize the faults_from, so all tasks in a group
|
|
|
|
* count according to CPU use, instead of by the raw
|
|
|
|
* number of faults. Tasks with little runtime have
|
|
|
|
* little over-all impact on throughput, and thus their
|
|
|
|
* faults are less important.
|
|
|
|
*/
|
|
|
|
f_weight = div64_u64(runtime << 16, period + 1);
|
2014-10-31 00:13:31 +00:00
|
|
|
f_weight = (f_weight * p->numa_faults[cpubuf_idx]) /
|
sched/numa: Normalize faults_cpu stats and weigh by CPU use
Tracing the code that decides the active nodes has made it abundantly clear
that the naive implementation of the faults_from code has issues.
Specifically, the garbage collector in some workloads will access orders
of magnitudes more memory than the threads that do all the active work.
This resulted in the node with the garbage collector being marked the only
active node in the group.
This issue is avoided if we weigh the statistics by CPU use of each task in
the numa group, instead of by how many faults each thread has occurred.
To achieve this, we normalize the number of faults to the fraction of faults
that occurred on each node, and then multiply that fraction by the fraction
of CPU time the task has used since the last time task_numa_placement was
invoked.
This way the nodes in the active node mask will be the ones where the tasks
from the numa group are most actively running, and the influence of eg. the
garbage collector and other do-little threads is properly minimized.
On a 4 node system, using CPU use statistics calculated over a longer interval
results in about 1% fewer page migrations with two 32-warehouse specjbb runs
on a 4 node system, and about 5% fewer page migrations, as well as 1% better
throughput, with two 8-warehouse specjbb runs, as compared with the shorter
term statistics kept by the scheduler.
Signed-off-by: Rik van Riel <riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Chegu Vinod <chegu_vinod@hp.com>
Link: http://lkml.kernel.org/r/1390860228-21539-7-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-01-27 22:03:45 +00:00
|
|
|
(total_faults + 1);
|
2014-10-31 00:13:31 +00:00
|
|
|
f_diff = f_weight - p->numa_faults[cpu_idx] / 2;
|
|
|
|
p->numa_faults[cpubuf_idx] = 0;
|
2014-01-27 22:03:42 +00:00
|
|
|
|
2014-10-31 00:13:31 +00:00
|
|
|
p->numa_faults[mem_idx] += diff;
|
|
|
|
p->numa_faults[cpu_idx] += f_diff;
|
|
|
|
faults += p->numa_faults[mem_idx];
|
2013-10-07 10:29:27 +00:00
|
|
|
p->total_numa_faults += diff;
|
2019-07-16 15:20:47 +00:00
|
|
|
if (ng) {
|
2014-10-31 00:13:31 +00:00
|
|
|
/*
|
|
|
|
* safe because we can only change our own group
|
|
|
|
*
|
|
|
|
* mem_idx represents the offset for a given
|
|
|
|
* nid and priv in a specific region because it
|
|
|
|
* is at the beginning of the numa_faults array.
|
|
|
|
*/
|
2019-07-16 15:20:47 +00:00
|
|
|
ng->faults[mem_idx] += diff;
|
|
|
|
ng->faults_cpu[mem_idx] += f_diff;
|
|
|
|
ng->total_faults += diff;
|
|
|
|
group_faults += ng->faults[mem_idx];
|
2013-10-07 10:29:21 +00:00
|
|
|
}
|
2013-10-07 10:29:03 +00:00
|
|
|
}
|
|
|
|
|
2019-07-16 15:20:47 +00:00
|
|
|
if (!ng) {
|
2018-06-20 17:02:46 +00:00
|
|
|
if (faults > max_faults) {
|
|
|
|
max_faults = faults;
|
|
|
|
max_nid = nid;
|
|
|
|
}
|
|
|
|
} else if (group_faults > max_faults) {
|
|
|
|
max_faults = group_faults;
|
2013-10-07 10:28:58 +00:00
|
|
|
max_nid = nid;
|
|
|
|
}
|
2013-10-07 10:29:27 +00:00
|
|
|
}
|
|
|
|
|
2019-07-16 15:20:47 +00:00
|
|
|
if (ng) {
|
|
|
|
numa_group_count_active_nodes(ng);
|
2014-04-07 08:55:15 +00:00
|
|
|
spin_unlock_irq(group_lock);
|
2018-06-20 17:02:46 +00:00
|
|
|
max_nid = preferred_group_nid(p, max_nid);
|
2013-10-07 10:28:58 +00:00
|
|
|
}
|
|
|
|
|
2014-06-04 20:33:15 +00:00
|
|
|
if (max_faults) {
|
|
|
|
/* Set the new preferred node */
|
|
|
|
if (max_nid != p->numa_preferred_nid)
|
|
|
|
sched_setnuma(p, max_nid);
|
2013-10-07 10:29:00 +00:00
|
|
|
}
|
2018-06-20 17:02:55 +00:00
|
|
|
|
|
|
|
update_task_scan_period(p, fault_types[0], fault_types[1]);
|
2012-10-25 12:16:43 +00:00
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:21 +00:00
|
|
|
static inline int get_numa_group(struct numa_group *grp)
|
|
|
|
{
|
2019-01-18 12:27:28 +00:00
|
|
|
return refcount_inc_not_zero(&grp->refcount);
|
2013-10-07 10:29:21 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void put_numa_group(struct numa_group *grp)
|
|
|
|
{
|
2019-01-18 12:27:28 +00:00
|
|
|
if (refcount_dec_and_test(&grp->refcount))
|
2013-10-07 10:29:21 +00:00
|
|
|
kfree_rcu(grp, rcu);
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:35 +00:00
|
|
|
static void task_numa_group(struct task_struct *p, int cpupid, int flags,
|
|
|
|
int *priv)
|
2013-10-07 10:29:21 +00:00
|
|
|
{
|
|
|
|
struct numa_group *grp, *my_grp;
|
|
|
|
struct task_struct *tsk;
|
|
|
|
bool join = false;
|
|
|
|
int cpu = cpupid_to_cpu(cpupid);
|
|
|
|
int i;
|
|
|
|
|
2019-07-16 15:20:47 +00:00
|
|
|
if (unlikely(!deref_curr_numa_group(p))) {
|
2013-10-07 10:29:21 +00:00
|
|
|
unsigned int size = sizeof(struct numa_group) +
|
2014-01-27 22:03:42 +00:00
|
|
|
4*nr_node_ids*sizeof(unsigned long);
|
2013-10-07 10:29:21 +00:00
|
|
|
|
|
|
|
grp = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
|
|
|
|
if (!grp)
|
|
|
|
return;
|
|
|
|
|
2019-01-18 12:27:28 +00:00
|
|
|
refcount_set(&grp->refcount, 1);
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
grp->active_nodes = 1;
|
|
|
|
grp->max_faults_cpu = 0;
|
2013-10-07 10:29:21 +00:00
|
|
|
spin_lock_init(&grp->lock);
|
2013-10-07 10:29:22 +00:00
|
|
|
grp->gid = p->pid;
|
2014-01-27 22:03:42 +00:00
|
|
|
/* Second half of the array tracks nids where faults happen */
|
2014-01-27 22:03:48 +00:00
|
|
|
grp->faults_cpu = grp->faults + NR_NUMA_HINT_FAULT_TYPES *
|
|
|
|
nr_node_ids;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
2014-01-27 22:03:48 +00:00
|
|
|
for (i = 0; i < NR_NUMA_HINT_FAULT_STATS * nr_node_ids; i++)
|
2014-10-31 00:13:31 +00:00
|
|
|
grp->faults[i] = p->numa_faults[i];
|
2013-10-07 10:29:21 +00:00
|
|
|
|
2013-10-07 10:29:40 +00:00
|
|
|
grp->total_faults = p->total_numa_faults;
|
2013-10-07 10:29:27 +00:00
|
|
|
|
2013-10-07 10:29:21 +00:00
|
|
|
grp->nr_tasks++;
|
|
|
|
rcu_assign_pointer(p->numa_group, grp);
|
|
|
|
}
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2015-04-28 20:00:20 +00:00
|
|
|
tsk = READ_ONCE(cpu_rq(cpu)->curr);
|
2013-10-07 10:29:21 +00:00
|
|
|
|
|
|
|
if (!cpupid_match_pid(tsk, cpupid))
|
2013-10-09 08:24:48 +00:00
|
|
|
goto no_join;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
|
|
|
grp = rcu_dereference(tsk->numa_group);
|
|
|
|
if (!grp)
|
2013-10-09 08:24:48 +00:00
|
|
|
goto no_join;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
2019-07-16 15:20:47 +00:00
|
|
|
my_grp = deref_curr_numa_group(p);
|
2013-10-07 10:29:21 +00:00
|
|
|
if (grp == my_grp)
|
2013-10-09 08:24:48 +00:00
|
|
|
goto no_join;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Only join the other group if its bigger; if we're the bigger group,
|
|
|
|
* the other task will join us.
|
|
|
|
*/
|
|
|
|
if (my_grp->nr_tasks > grp->nr_tasks)
|
2013-10-09 08:24:48 +00:00
|
|
|
goto no_join;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Tie-break on the grp address.
|
|
|
|
*/
|
|
|
|
if (my_grp->nr_tasks == grp->nr_tasks && my_grp > grp)
|
2013-10-09 08:24:48 +00:00
|
|
|
goto no_join;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
2013-10-07 10:29:34 +00:00
|
|
|
/* Always join threads in the same process. */
|
|
|
|
if (tsk->mm == current->mm)
|
|
|
|
join = true;
|
|
|
|
|
|
|
|
/* Simple filter to avoid false positives due to PID collisions */
|
|
|
|
if (flags & TNF_SHARED)
|
|
|
|
join = true;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
2013-10-07 10:29:35 +00:00
|
|
|
/* Update priv based on whether false sharing was detected */
|
|
|
|
*priv = !join;
|
|
|
|
|
2013-10-07 10:29:34 +00:00
|
|
|
if (join && !get_numa_group(grp))
|
2013-10-09 08:24:48 +00:00
|
|
|
goto no_join;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
if (!join)
|
|
|
|
return;
|
|
|
|
|
2014-04-07 08:55:15 +00:00
|
|
|
BUG_ON(irqs_disabled());
|
|
|
|
double_lock_irq(&my_grp->lock, &grp->lock);
|
2013-10-07 10:29:40 +00:00
|
|
|
|
2014-01-27 22:03:48 +00:00
|
|
|
for (i = 0; i < NR_NUMA_HINT_FAULT_STATS * nr_node_ids; i++) {
|
2014-10-31 00:13:31 +00:00
|
|
|
my_grp->faults[i] -= p->numa_faults[i];
|
|
|
|
grp->faults[i] += p->numa_faults[i];
|
2013-10-07 10:29:21 +00:00
|
|
|
}
|
2013-10-07 10:29:40 +00:00
|
|
|
my_grp->total_faults -= p->total_numa_faults;
|
|
|
|
grp->total_faults += p->total_numa_faults;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
|
|
|
my_grp->nr_tasks--;
|
|
|
|
grp->nr_tasks++;
|
|
|
|
|
|
|
|
spin_unlock(&my_grp->lock);
|
2014-04-07 08:55:15 +00:00
|
|
|
spin_unlock_irq(&grp->lock);
|
2013-10-07 10:29:21 +00:00
|
|
|
|
|
|
|
rcu_assign_pointer(p->numa_group, grp);
|
|
|
|
|
|
|
|
put_numa_group(my_grp);
|
2013-10-09 08:24:48 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
no_join:
|
|
|
|
rcu_read_unlock();
|
|
|
|
return;
|
2013-10-07 10:29:21 +00:00
|
|
|
}
|
|
|
|
|
2019-07-16 15:20:45 +00:00
|
|
|
/*
|
|
|
|
* Get rid of NUMA staticstics associated with a task (either current or dead).
|
|
|
|
* If @final is set, the task is dead and has reached refcount zero, so we can
|
|
|
|
* safely free all relevant data structures. Otherwise, there might be
|
|
|
|
* concurrent reads from places like load balancing and procfs, and we should
|
|
|
|
* reset the data back to default state without freeing ->numa_faults.
|
|
|
|
*/
|
|
|
|
void task_numa_free(struct task_struct *p, bool final)
|
2013-10-07 10:29:21 +00:00
|
|
|
{
|
2019-07-16 15:20:47 +00:00
|
|
|
/* safe: p either is current or is being freed by current */
|
|
|
|
struct numa_group *grp = rcu_dereference_raw(p->numa_group);
|
2019-07-16 15:20:45 +00:00
|
|
|
unsigned long *numa_faults = p->numa_faults;
|
2014-05-27 21:02:04 +00:00
|
|
|
unsigned long flags;
|
|
|
|
int i;
|
2013-10-07 10:29:21 +00:00
|
|
|
|
2019-07-16 15:20:45 +00:00
|
|
|
if (!numa_faults)
|
|
|
|
return;
|
|
|
|
|
2013-10-07 10:29:21 +00:00
|
|
|
if (grp) {
|
2014-05-27 21:02:04 +00:00
|
|
|
spin_lock_irqsave(&grp->lock, flags);
|
2014-01-27 22:03:48 +00:00
|
|
|
for (i = 0; i < NR_NUMA_HINT_FAULT_STATS * nr_node_ids; i++)
|
2014-10-31 00:13:31 +00:00
|
|
|
grp->faults[i] -= p->numa_faults[i];
|
2013-10-07 10:29:40 +00:00
|
|
|
grp->total_faults -= p->total_numa_faults;
|
2013-10-07 10:29:27 +00:00
|
|
|
|
2013-10-07 10:29:21 +00:00
|
|
|
grp->nr_tasks--;
|
2014-05-27 21:02:04 +00:00
|
|
|
spin_unlock_irqrestore(&grp->lock, flags);
|
2014-08-22 14:50:43 +00:00
|
|
|
RCU_INIT_POINTER(p->numa_group, NULL);
|
2013-10-07 10:29:21 +00:00
|
|
|
put_numa_group(grp);
|
|
|
|
}
|
|
|
|
|
2019-07-16 15:20:45 +00:00
|
|
|
if (final) {
|
|
|
|
p->numa_faults = NULL;
|
|
|
|
kfree(numa_faults);
|
|
|
|
} else {
|
|
|
|
p->total_numa_faults = 0;
|
|
|
|
for (i = 0; i < NR_NUMA_HINT_FAULT_STATS * nr_node_ids; i++)
|
|
|
|
numa_faults[i] = 0;
|
|
|
|
}
|
2013-10-07 10:29:21 +00:00
|
|
|
}
|
|
|
|
|
2012-10-25 12:16:43 +00:00
|
|
|
/*
|
|
|
|
* Got a PROT_NONE fault for a page on @node.
|
|
|
|
*/
|
2014-01-27 22:03:47 +00:00
|
|
|
void task_numa_fault(int last_cpupid, int mem_node, int pages, int flags)
|
2012-10-25 12:16:43 +00:00
|
|
|
{
|
|
|
|
struct task_struct *p = current;
|
2013-10-07 10:29:24 +00:00
|
|
|
bool migrated = flags & TNF_MIGRATED;
|
2014-01-27 22:03:47 +00:00
|
|
|
int cpu_node = task_node(current);
|
2014-04-11 17:00:27 +00:00
|
|
|
int local = !!(flags & TNF_FAULT_LOCAL);
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
struct numa_group *ng;
|
2013-10-07 10:29:03 +00:00
|
|
|
int priv;
|
2012-10-25 12:16:43 +00:00
|
|
|
|
2015-08-11 16:24:21 +00:00
|
|
|
if (!static_branch_likely(&sched_numa_balancing))
|
2012-11-22 11:16:36 +00:00
|
|
|
return;
|
|
|
|
|
2013-10-07 10:29:04 +00:00
|
|
|
/* for example, ksmd faulting in a user's mm */
|
|
|
|
if (!p->mm)
|
|
|
|
return;
|
|
|
|
|
2013-10-07 10:28:57 +00:00
|
|
|
/* Allocate buffer to track faults on a per-node basis */
|
2014-10-31 00:13:31 +00:00
|
|
|
if (unlikely(!p->numa_faults)) {
|
|
|
|
int size = sizeof(*p->numa_faults) *
|
2014-01-27 22:03:48 +00:00
|
|
|
NR_NUMA_HINT_FAULT_BUCKETS * nr_node_ids;
|
2013-10-07 10:28:57 +00:00
|
|
|
|
2014-10-31 00:13:31 +00:00
|
|
|
p->numa_faults = kzalloc(size, GFP_KERNEL|__GFP_NOWARN);
|
|
|
|
if (!p->numa_faults)
|
2013-10-07 10:28:57 +00:00
|
|
|
return;
|
2013-10-07 10:28:59 +00:00
|
|
|
|
2013-10-07 10:29:27 +00:00
|
|
|
p->total_numa_faults = 0;
|
2013-10-07 10:29:36 +00:00
|
|
|
memset(p->numa_faults_locality, 0, sizeof(p->numa_faults_locality));
|
2013-10-07 10:28:57 +00:00
|
|
|
}
|
2012-10-25 12:16:43 +00:00
|
|
|
|
2013-10-07 10:29:21 +00:00
|
|
|
/*
|
|
|
|
* First accesses are treated as private, otherwise consider accesses
|
|
|
|
* to be private if the accessing pid has not changed
|
|
|
|
*/
|
|
|
|
if (unlikely(last_cpupid == (-1 & LAST_CPUPID_MASK))) {
|
|
|
|
priv = 1;
|
|
|
|
} else {
|
|
|
|
priv = cpupid_match_pid(p, last_cpupid);
|
2013-10-07 10:29:24 +00:00
|
|
|
if (!priv && !(flags & TNF_NO_GROUP))
|
2013-10-07 10:29:35 +00:00
|
|
|
task_numa_group(p, last_cpupid, flags, &priv);
|
2013-10-07 10:29:21 +00:00
|
|
|
}
|
|
|
|
|
2014-04-11 17:00:27 +00:00
|
|
|
/*
|
|
|
|
* If a workload spans multiple NUMA nodes, a shared fault that
|
|
|
|
* occurs wholly within the set of nodes that the workload is
|
|
|
|
* actively using should be counted as local. This allows the
|
|
|
|
* scan rate to slow down when a workload has settled down.
|
|
|
|
*/
|
2019-07-16 15:20:47 +00:00
|
|
|
ng = deref_curr_numa_group(p);
|
sched/numa: Spread memory according to CPU and memory use
The pseudo-interleaving in NUMA placement has a fundamental problem:
using hard usage thresholds to spread memory equally between nodes
can prevent workloads from converging, or keep memory "trapped" on
nodes where the workload is barely running any more.
In order for workloads to properly converge, the memory migration
should not be stopped when nodes reach parity, but instead be
distributed according to how heavily memory is used from each node.
This way memory migration and task migration reinforce each other,
instead of one putting the brakes on the other.
Remove the hard thresholds from the pseudo-interleaving code, and
instead use a more gradual policy on memory placement. This also
seems to improve convergence of workloads that do not run flat out,
but sleep in between bursts of activity.
We still want to slow down NUMA scanning and migration once a workload
has settled on a few actively used nodes, so keep the 3/4 hysteresis
in place. Keep track of whether a workload is actively running on
multiple nodes, so task_numa_migrate does a full scan of the system
for better task placement.
In the case of running 3 SPECjbb2005 instances on a 4 node system,
this code seems to result in fairer distribution of memory between
nodes, with more memory bandwidth for each instance.
Signed-off-by: Rik van Riel <riel@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/20160125170739.2fc9a641@annuminas.surriel.com
[ Minor readability tweaks. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-01-25 22:07:39 +00:00
|
|
|
if (!priv && !local && ng && ng->active_nodes > 1 &&
|
|
|
|
numa_is_active_node(cpu_node, ng) &&
|
|
|
|
numa_is_active_node(mem_node, ng))
|
2014-04-11 17:00:27 +00:00
|
|
|
local = 1;
|
|
|
|
|
2013-10-07 10:29:41 +00:00
|
|
|
/*
|
2018-11-05 00:50:13 +00:00
|
|
|
* Retry to migrate task to preferred node periodically, in case it
|
|
|
|
* previously failed, or the scheduler moved us.
|
2013-10-07 10:29:41 +00:00
|
|
|
*/
|
2018-06-20 17:03:00 +00:00
|
|
|
if (time_after(jiffies, p->numa_migrate_retry)) {
|
|
|
|
task_numa_placement(p);
|
2013-10-07 10:29:11 +00:00
|
|
|
numa_migrate_preferred(p);
|
2018-06-20 17:03:00 +00:00
|
|
|
}
|
2013-10-07 10:29:11 +00:00
|
|
|
|
2013-10-07 10:29:30 +00:00
|
|
|
if (migrated)
|
|
|
|
p->numa_pages_migrated += pages;
|
2015-03-25 22:55:42 +00:00
|
|
|
if (flags & TNF_MIGRATE_FAIL)
|
|
|
|
p->numa_faults_locality[2] += pages;
|
2013-10-07 10:29:30 +00:00
|
|
|
|
2014-10-31 00:13:31 +00:00
|
|
|
p->numa_faults[task_faults_idx(NUMA_MEMBUF, mem_node, priv)] += pages;
|
|
|
|
p->numa_faults[task_faults_idx(NUMA_CPUBUF, cpu_node, priv)] += pages;
|
2014-04-11 17:00:27 +00:00
|
|
|
p->numa_faults_locality[local] += pages;
|
2012-10-25 12:16:43 +00:00
|
|
|
}
|
|
|
|
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
static void reset_ptenuma_scan(struct task_struct *p)
|
|
|
|
{
|
2015-05-01 00:28:14 +00:00
|
|
|
/*
|
|
|
|
* We only did a read acquisition of the mmap sem, so
|
|
|
|
* p->mm->numa_scan_seq is written to without exclusive access
|
|
|
|
* and the update is not guaranteed to be atomic. That's not
|
|
|
|
* much of an issue though, since this is just used for
|
|
|
|
* statistical sampling. Use READ_ONCE/WRITE_ONCE, which are not
|
|
|
|
* expensive, to avoid any form of compiler optimizations:
|
|
|
|
*/
|
2015-04-28 20:00:20 +00:00
|
|
|
WRITE_ONCE(p->mm->numa_scan_seq, READ_ONCE(p->mm->numa_scan_seq) + 1);
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
p->mm->numa_scan_offset = 0;
|
|
|
|
}
|
|
|
|
|
2012-10-25 12:16:43 +00:00
|
|
|
/*
|
|
|
|
* The expensive part of numa migration is done from task_work context.
|
|
|
|
* Triggered from task_tick_numa().
|
|
|
|
*/
|
2019-07-15 10:25:08 +00:00
|
|
|
static void task_numa_work(struct callback_head *work)
|
2012-10-25 12:16:43 +00:00
|
|
|
{
|
|
|
|
unsigned long migrate, next_scan, now = jiffies;
|
|
|
|
struct task_struct *p = current;
|
|
|
|
struct mm_struct *mm = p->mm;
|
sched/numa: Cap PTE scanning overhead to 3% of run time
There is a fundamental mismatch between the runtime based NUMA scanning
at the task level, and the wall clock time NUMA scanning at the mm level.
On a severely overloaded system, with very large processes, this mismatch
can cause the system to spend all of its time in change_prot_numa().
This can happen if the task spends at least two ticks in change_prot_numa(),
and only gets two ticks of CPU time in the real time between two scan
intervals of the mm.
This patch ensures that a task never spends more than 3% of run
time scanning PTEs. It does that by ensuring that in-between
task_numa_work() runs, the task spends at least 32x as much time on
other things than it did on task_numa_work().
This is done stochastically: if a timer tick happens, or the task
gets rescheduled during task_numa_work(), we delay a future run of
task_numa_work() until the task has spent at least 32x the amount of
CPU time doing something else, as it spent inside task_numa_work().
The longer task_numa_work() takes, the more likely it is this happens.
If task_numa_work() takes very little time, chances are low that that
code will do anything, but we will not care.
Reported-and-tested-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/1446756983-28173-3-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-11-05 20:56:23 +00:00
|
|
|
u64 runtime = p->se.sum_exec_runtime;
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
struct vm_area_struct *vma;
|
2012-11-14 18:34:32 +00:00
|
|
|
unsigned long start, end;
|
2013-10-07 10:28:55 +00:00
|
|
|
unsigned long nr_pte_updates = 0;
|
2015-09-11 13:00:27 +00:00
|
|
|
long pages, virtpages;
|
2012-10-25 12:16:43 +00:00
|
|
|
|
2016-09-20 20:34:51 +00:00
|
|
|
SCHED_WARN_ON(p != container_of(work, struct task_struct, numa_work));
|
2012-10-25 12:16:43 +00:00
|
|
|
|
2019-07-15 10:25:07 +00:00
|
|
|
work->next = work;
|
2012-10-25 12:16:43 +00:00
|
|
|
/*
|
|
|
|
* Who cares about NUMA placement when they're dying.
|
|
|
|
*
|
|
|
|
* NOTE: make sure not to dereference p->mm before this check,
|
|
|
|
* exit_task_work() happens _after_ exit_mm() so we could be called
|
|
|
|
* without p->mm even though we still had it when we enqueued this
|
|
|
|
* work.
|
|
|
|
*/
|
|
|
|
if (p->flags & PF_EXITING)
|
|
|
|
return;
|
|
|
|
|
2013-10-07 10:29:37 +00:00
|
|
|
if (!mm->numa_next_scan) {
|
2013-10-07 10:28:54 +00:00
|
|
|
mm->numa_next_scan = now +
|
|
|
|
msecs_to_jiffies(sysctl_numa_balancing_scan_delay);
|
2012-11-21 01:18:23 +00:00
|
|
|
}
|
|
|
|
|
2012-10-25 12:16:43 +00:00
|
|
|
/*
|
|
|
|
* Enforce maximal scan/migration frequency..
|
|
|
|
*/
|
|
|
|
migrate = mm->numa_next_scan;
|
|
|
|
if (time_before(now, migrate))
|
|
|
|
return;
|
|
|
|
|
2013-10-07 10:28:55 +00:00
|
|
|
if (p->numa_scan_period == 0) {
|
|
|
|
p->numa_scan_period_max = task_scan_max(p);
|
2017-07-31 19:28:47 +00:00
|
|
|
p->numa_scan_period = task_scan_start(p);
|
2013-10-07 10:28:55 +00:00
|
|
|
}
|
2012-10-25 12:16:43 +00:00
|
|
|
|
2012-11-15 09:01:14 +00:00
|
|
|
next_scan = now + msecs_to_jiffies(p->numa_scan_period);
|
2012-10-25 12:16:43 +00:00
|
|
|
if (cmpxchg(&mm->numa_next_scan, migrate, next_scan) != migrate)
|
|
|
|
return;
|
|
|
|
|
2013-10-07 10:28:51 +00:00
|
|
|
/*
|
|
|
|
* Delay this task enough that another task of this mm will likely win
|
|
|
|
* the next time around.
|
|
|
|
*/
|
|
|
|
p->node_stamp += 2 * TICK_NSEC;
|
|
|
|
|
2012-11-14 18:34:32 +00:00
|
|
|
start = mm->numa_scan_offset;
|
|
|
|
pages = sysctl_numa_balancing_scan_size;
|
|
|
|
pages <<= 20 - PAGE_SHIFT; /* MB in pages */
|
2015-09-11 13:00:27 +00:00
|
|
|
virtpages = pages * 8; /* Scan up to this much virtual space */
|
2012-11-14 18:34:32 +00:00
|
|
|
if (!pages)
|
|
|
|
return;
|
2012-10-25 12:16:43 +00:00
|
|
|
|
2015-09-11 13:00:27 +00:00
|
|
|
|
2017-05-15 13:13:16 +00:00
|
|
|
if (!down_read_trylock(&mm->mmap_sem))
|
|
|
|
return;
|
2012-11-14 18:34:32 +00:00
|
|
|
vma = find_vma(mm, start);
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
if (!vma) {
|
|
|
|
reset_ptenuma_scan(p);
|
2012-11-14 18:34:32 +00:00
|
|
|
start = 0;
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
vma = mm->mmap;
|
|
|
|
}
|
2012-11-14 18:34:32 +00:00
|
|
|
for (; vma; vma = vma->vm_next) {
|
2015-04-07 21:26:47 +00:00
|
|
|
if (!vma_migratable(vma) || !vma_policy_mof(vma) ||
|
2015-06-10 18:15:00 +00:00
|
|
|
is_vm_hugetlb_page(vma) || (vma->vm_flags & VM_MIXEDMAP)) {
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
continue;
|
2015-04-07 21:26:47 +00:00
|
|
|
}
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
|
2013-10-07 10:29:13 +00:00
|
|
|
/*
|
|
|
|
* Shared library pages mapped by multiple processes are not
|
|
|
|
* migrated as it is expected they are cache replicated. Avoid
|
|
|
|
* hinting faults in read-only file-backed mappings or the vdso
|
|
|
|
* as migrating the pages will be of marginal benefit.
|
|
|
|
*/
|
|
|
|
if (!vma->vm_mm ||
|
|
|
|
(vma->vm_file && (vma->vm_flags & (VM_READ|VM_WRITE)) == (VM_READ)))
|
|
|
|
continue;
|
|
|
|
|
2013-12-19 01:08:40 +00:00
|
|
|
/*
|
|
|
|
* Skip inaccessible VMAs to avoid any confusion between
|
|
|
|
* PROT_NONE and NUMA hinting ptes
|
|
|
|
*/
|
|
|
|
if (!(vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE)))
|
|
|
|
continue;
|
2013-10-07 10:29:13 +00:00
|
|
|
|
2012-11-14 18:34:32 +00:00
|
|
|
do {
|
|
|
|
start = max(start, vma->vm_start);
|
|
|
|
end = ALIGN(start + (pages << PAGE_SHIFT), HPAGE_SIZE);
|
|
|
|
end = min(end, vma->vm_end);
|
2015-09-11 13:00:27 +00:00
|
|
|
nr_pte_updates = change_prot_numa(vma, start, end);
|
2013-10-07 10:28:55 +00:00
|
|
|
|
|
|
|
/*
|
2015-09-11 13:00:27 +00:00
|
|
|
* Try to scan sysctl_numa_balancing_size worth of
|
|
|
|
* hpages that have at least one present PTE that
|
|
|
|
* is not already pte-numa. If the VMA contains
|
|
|
|
* areas that are unused or already full of prot_numa
|
|
|
|
* PTEs, scan up to virtpages, to skip through those
|
|
|
|
* areas faster.
|
2013-10-07 10:28:55 +00:00
|
|
|
*/
|
|
|
|
if (nr_pte_updates)
|
|
|
|
pages -= (end - start) >> PAGE_SHIFT;
|
2015-09-11 13:00:27 +00:00
|
|
|
virtpages -= (end - start) >> PAGE_SHIFT;
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
|
2012-11-14 18:34:32 +00:00
|
|
|
start = end;
|
2015-09-11 13:00:27 +00:00
|
|
|
if (pages <= 0 || virtpages <= 0)
|
2012-11-14 18:34:32 +00:00
|
|
|
goto out;
|
2014-02-18 22:12:44 +00:00
|
|
|
|
|
|
|
cond_resched();
|
2012-11-14 18:34:32 +00:00
|
|
|
} while (end != vma->vm_end);
|
2012-10-25 12:16:43 +00:00
|
|
|
}
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
|
2012-11-14 18:34:32 +00:00
|
|
|
out:
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
/*
|
2013-10-07 10:28:41 +00:00
|
|
|
* It is possible to reach the end of the VMA list but the last few
|
|
|
|
* VMAs are not guaranteed to the vma_migratable. If they are not, we
|
|
|
|
* would find the !migratable VMA on the next scan but not reset the
|
|
|
|
* scanner to the start so check it now.
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
*/
|
|
|
|
if (vma)
|
2012-11-14 18:34:32 +00:00
|
|
|
mm->numa_scan_offset = start;
|
mm: sched: numa: Implement constant, per task Working Set Sampling (WSS) rate
Previously, to probe the working set of a task, we'd use
a very simple and crude method: mark all of its address
space PROT_NONE.
That method has various (obvious) disadvantages:
- it samples the working set at dissimilar rates,
giving some tasks a sampling quality advantage
over others.
- creates performance problems for tasks with very
large working sets
- over-samples processes with large address spaces but
which only very rarely execute
Improve that method by keeping a rotating offset into the
address space that marks the current position of the scan,
and advance it by a constant rate (in a CPU cycles execution
proportional manner). If the offset reaches the last mapped
address of the mm then it then it starts over at the first
address.
The per-task nature of the working set sampling functionality in this tree
allows such constant rate, per task, execution-weight proportional sampling
of the working set, with an adaptive sampling interval/frequency that
goes from once per 100ms up to just once per 8 seconds. The current
sampling volume is 256 MB per interval.
As tasks mature and converge their working set, so does the
sampling rate slow down to just a trickle, 256 MB per 8
seconds of CPU time executed.
This, beyond being adaptive, also rate-limits rarely
executing systems and does not over-sample on overloaded
systems.
[ In AutoNUMA speak, this patch deals with the effective sampling
rate of the 'hinting page fault'. AutoNUMA's scanning is
currently rate-limited, but it is also fundamentally
single-threaded, executing in the knuma_scand kernel thread,
so the limit in AutoNUMA is global and does not scale up with
the number of CPUs, nor does it scan tasks in an execution
proportional manner.
So the idea of rate-limiting the scanning was first implemented
in the AutoNUMA tree via a global rate limit. This patch goes
beyond that by implementing an execution rate proportional
working set sampling rate that is not implemented via a single
global scanning daemon. ]
[ Dan Carpenter pointed out a possible NULL pointer dereference in the
first version of this patch. ]
Based-on-idea-by: Andrea Arcangeli <aarcange@redhat.com>
Bug-Found-By: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
[ Wrote changelog and fixed bug. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
2012-10-25 12:16:45 +00:00
|
|
|
else
|
|
|
|
reset_ptenuma_scan(p);
|
|
|
|
up_read(&mm->mmap_sem);
|
sched/numa: Cap PTE scanning overhead to 3% of run time
There is a fundamental mismatch between the runtime based NUMA scanning
at the task level, and the wall clock time NUMA scanning at the mm level.
On a severely overloaded system, with very large processes, this mismatch
can cause the system to spend all of its time in change_prot_numa().
This can happen if the task spends at least two ticks in change_prot_numa(),
and only gets two ticks of CPU time in the real time between two scan
intervals of the mm.
This patch ensures that a task never spends more than 3% of run
time scanning PTEs. It does that by ensuring that in-between
task_numa_work() runs, the task spends at least 32x as much time on
other things than it did on task_numa_work().
This is done stochastically: if a timer tick happens, or the task
gets rescheduled during task_numa_work(), we delay a future run of
task_numa_work() until the task has spent at least 32x the amount of
CPU time doing something else, as it spent inside task_numa_work().
The longer task_numa_work() takes, the more likely it is this happens.
If task_numa_work() takes very little time, chances are low that that
code will do anything, but we will not care.
Reported-and-tested-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: mgorman@suse.de
Link: http://lkml.kernel.org/r/1446756983-28173-3-git-send-email-riel@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-11-05 20:56:23 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure tasks use at least 32x as much time to run other code
|
|
|
|
* than they used here, to limit NUMA PTE scanning overhead to 3% max.
|
|
|
|
* Usually update_task_scan_period slows down scanning enough; on an
|
|
|
|
* overloaded system we need to limit overhead on a per task basis.
|
|
|
|
*/
|
|
|
|
if (unlikely(p->se.sum_exec_runtime != runtime)) {
|
|
|
|
u64 diff = p->se.sum_exec_runtime - runtime;
|
|
|
|
p->node_stamp += 32 * diff;
|
|
|
|
}
|
2012-10-25 12:16:43 +00:00
|
|
|
}
|
|
|
|
|
2019-07-15 10:25:06 +00:00
|
|
|
void init_numa_balancing(unsigned long clone_flags, struct task_struct *p)
|
|
|
|
{
|
|
|
|
int mm_users = 0;
|
|
|
|
struct mm_struct *mm = p->mm;
|
|
|
|
|
|
|
|
if (mm) {
|
|
|
|
mm_users = atomic_read(&mm->mm_users);
|
|
|
|
if (mm_users == 1) {
|
|
|
|
mm->numa_next_scan = jiffies + msecs_to_jiffies(sysctl_numa_balancing_scan_delay);
|
|
|
|
mm->numa_scan_seq = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
p->node_stamp = 0;
|
|
|
|
p->numa_scan_seq = mm ? mm->numa_scan_seq : 0;
|
|
|
|
p->numa_scan_period = sysctl_numa_balancing_scan_delay;
|
2019-07-15 10:25:07 +00:00
|
|
|
/* Protect against double add, see task_tick_numa and task_numa_work */
|
2019-07-15 10:25:06 +00:00
|
|
|
p->numa_work.next = &p->numa_work;
|
|
|
|
p->numa_faults = NULL;
|
|
|
|
RCU_INIT_POINTER(p->numa_group, NULL);
|
|
|
|
p->last_task_numa_placement = 0;
|
|
|
|
p->last_sum_exec_runtime = 0;
|
|
|
|
|
2019-07-15 10:25:07 +00:00
|
|
|
init_task_work(&p->numa_work, task_numa_work);
|
|
|
|
|
2019-07-15 10:25:06 +00:00
|
|
|
/* New address space, reset the preferred nid */
|
|
|
|
if (!(clone_flags & CLONE_VM)) {
|
|
|
|
p->numa_preferred_nid = NUMA_NO_NODE;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* New thread, keep existing numa_preferred_nid which should be copied
|
|
|
|
* already by arch_dup_task_struct but stagger when scans start.
|
|
|
|
*/
|
|
|
|
if (mm) {
|
|
|
|
unsigned int delay;
|
|
|
|
|
|
|
|
delay = min_t(unsigned int, task_scan_max(current),
|
|
|
|
current->numa_scan_period * mm_users * NSEC_PER_MSEC);
|
|
|
|
delay += 2 * TICK_NSEC;
|
|
|
|
p->node_stamp = delay;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-25 12:16:43 +00:00
|
|
|
/*
|
|
|
|
* Drive the periodic memory faults..
|
|
|
|
*/
|
2019-04-18 14:47:13 +00:00
|
|
|
static void task_tick_numa(struct rq *rq, struct task_struct *curr)
|
2012-10-25 12:16:43 +00:00
|
|
|
{
|
|
|
|
struct callback_head *work = &curr->numa_work;
|
|
|
|
u64 period, now;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We don't care about NUMA placement if we don't have memory.
|
|
|
|
*/
|
|
|
|
if (!curr->mm || (curr->flags & PF_EXITING) || work->next != work)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Using runtime rather than walltime has the dual advantage that
|
|
|
|
* we (mostly) drive the selection from busy threads and that the
|
|
|
|
* task needs to have done some actual work before we bother with
|
|
|
|
* NUMA placement.
|
|
|
|
*/
|
|
|
|
now = curr->se.sum_exec_runtime;
|
|
|
|
period = (u64)curr->numa_scan_period * NSEC_PER_MSEC;
|
|
|
|
|
2015-11-05 20:56:22 +00:00
|
|
|
if (now > curr->node_stamp + period) {
|
2012-10-25 12:16:47 +00:00
|
|
|
if (!curr->node_stamp)
|
2017-07-31 19:28:47 +00:00
|
|
|
curr->numa_scan_period = task_scan_start(curr);
|
2013-10-07 10:28:51 +00:00
|
|
|
curr->node_stamp += period;
|
2012-10-25 12:16:43 +00:00
|
|
|
|
2019-07-15 10:25:07 +00:00
|
|
|
if (!time_before(jiffies, curr->mm->numa_next_scan))
|
2012-10-25 12:16:43 +00:00
|
|
|
task_work_add(curr, work, true);
|
|
|
|
}
|
|
|
|
}
|
2017-06-23 16:55:29 +00:00
|
|
|
|
sched/numa: Reset scan rate whenever task moves across nodes
Currently task scan rate is reset when NUMA balancer migrates the task
to a different node. If NUMA balancer initiates a swap, reset is only
applicable to the task that initiates the swap. Similarly no scan rate
reset is done if the task is migrated across nodes by traditional load
balancer.
Instead move the scan reset to the migrate_task_rq. This ensures the
task moved out of its preferred node, either gets back to its preferred
node quickly or finds a new preferred node. Doing so, would be fair to
all tasks migrating across nodes.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200668 203370 1.3465
1 321791 328431 2.06345
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 204848 206070 0.59654
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 188098 188386 0.153112
1 200351 201566 0.606436
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 58145.9 59157.4 1.73959
1 103798 105495 1.63491
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,912,183 13,825,492
migrations 1,155,931 1,152,509
faults 367,139 371,948
cache-misses 54,240,196,814 55,654,206,041
sched:sched_move_numa 1,571 1,856
sched:sched_stick_numa 9 4
sched:sched_swap_numa 463 428
migrate:mm_migrate_pages 703 898
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 50155 57146
numa_hint_faults_local 45264 51612
numa_hit 239652 238164
numa_huge_pte_updates 36 16
numa_interleave 68 63
numa_local 239576 238085
numa_other 76 79
numa_pages_migrated 680 883
numa_pte_updates 71146 67540
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,156,720 3,288,525
migrations 30,354 38,652
faults 97,261 111,678
cache-misses 12,400,026,826 12,111,197,376
sched:sched_move_numa 4 900
sched:sched_stick_numa 0 0
sched:sched_swap_numa 1 5
migrate:mm_migrate_pages 20 714
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 272 18572
numa_hint_faults_local 186 14850
numa_hit 71362 73197
numa_huge_pte_updates 0 11
numa_interleave 23 25
numa_local 71299 73138
numa_other 63 59
numa_pages_migrated 2 712
numa_pte_updates 0 24021
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,606,824 8,451,543
migrations 155,352 202,804
faults 301,409 310,024
cache-misses 157,759,224 253,522,507
sched:sched_move_numa 168 213
sched:sched_stick_numa 0 0
sched:sched_swap_numa 3 2
migrate:mm_migrate_pages 125 88
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 4650 11830
numa_hint_faults_local 3946 11301
numa_hit 90489 90038
numa_huge_pte_updates 0 0
numa_interleave 892 855
numa_local 90034 89796
numa_other 455 242
numa_pages_migrated 124 88
numa_pte_updates 4818 12039
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,113,167 2,049,153
migrations 10,533 11,405
faults 142,727 162,309
cache-misses 5,594,192 7,203,343
sched:sched_move_numa 10 22
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 6 1
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 744 1693
numa_hint_faults_local 584 1669
numa_hit 25551 25177
numa_huge_pte_updates 0 0
numa_interleave 263 194
numa_local 25302 24993
numa_other 249 184
numa_pages_migrated 6 1
numa_pte_updates 744 1577
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 101,227,352 94,515,937
migrations 4,151,829 4,203,554
faults 745,233 832,697
cache-misses 224,669,561,766 226,248,698,331
sched:sched_move_numa 617 1,730
sched:sched_stick_numa 2 14
sched:sched_swap_numa 187 432
migrate:mm_migrate_pages 316 1,398
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 24195 80079
numa_hint_faults_local 21639 68620
numa_hit 238331 241187
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 238331 241186
numa_other 0 1
numa_pages_migrated 204 1347
numa_pte_updates 24561 80729
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 62,738,978 63,704,961
migrations 562,702 573,404
faults 228,465 230,878
cache-misses 75,778,067,952 76,568,222,781
sched:sched_move_numa 648 509
sched:sched_stick_numa 13 31
sched:sched_swap_numa 137 182
migrate:mm_migrate_pages 733 541
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 10281 8501
numa_hint_faults_local 3242 2960
numa_hit 36338 35526
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 36338 35526
numa_other 0 0
numa_pages_migrated 706 539
numa_pte_updates 10176 8433
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-4-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:58 +00:00
|
|
|
static void update_scan_period(struct task_struct *p, int new_cpu)
|
|
|
|
{
|
|
|
|
int src_nid = cpu_to_node(task_cpu(p));
|
|
|
|
int dst_nid = cpu_to_node(new_cpu);
|
|
|
|
|
sched/numa: Limit the conditions where scan period is reset
migrate_task_rq_fair() resets the scan rate for NUMA balancing on every
cross-node migration. In the event of excessive load balancing due to
saturation, this may result in the scan rate being pegged at maximum and
further overloading the machine.
This patch only resets the scan if NUMA balancing is active, a preferred
node has been selected and the task is being migrated from the preferred
node as these are the most harmful. For example, a migration to the preferred
node does not justify a faster scan rate. Similarly, a migration between two
nodes that are not preferred is probably bouncing due to over-saturation of
the machine. In that case, scanning faster and trapping more NUMA faults
will further overload the machine.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 203370 205332 0.964744
1 328431 319785 -2.63252
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 206070 206585 0.249915
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 188386 189162 0.41192
1 201566 213760 6.04963
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 59157.4 58736.8 -0.710985
1 105495 105419 -0.0720413
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,825,492 14,285,708
migrations 1,152,509 1,180,621
faults 371,948 339,114
cache-misses 55,654,206,041 55,205,631,894
sched:sched_move_numa 1,856 843
sched:sched_stick_numa 4 6
sched:sched_swap_numa 428 219
migrate:mm_migrate_pages 898 365
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 57146 26907
numa_hint_faults_local 51612 24279
numa_hit 238164 239771
numa_huge_pte_updates 16 0
numa_interleave 63 68
numa_local 238085 239688
numa_other 79 83
numa_pages_migrated 883 363
numa_pte_updates 67540 27415
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,288,525 3,202,779
migrations 38,652 37,186
faults 111,678 106,076
cache-misses 12,111,197,376 12,024,873,744
sched:sched_move_numa 900 931
sched:sched_stick_numa 0 0
sched:sched_swap_numa 5 1
migrate:mm_migrate_pages 714 637
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 18572 17409
numa_hint_faults_local 14850 14367
numa_hit 73197 73953
numa_huge_pte_updates 11 20
numa_interleave 25 25
numa_local 73138 73892
numa_other 59 61
numa_pages_migrated 712 668
numa_pte_updates 24021 27276
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,451,543 8,474,013
migrations 202,804 254,934
faults 310,024 320,506
cache-misses 253,522,507 110,580,458
sched:sched_move_numa 213 725
sched:sched_stick_numa 0 0
sched:sched_swap_numa 2 7
migrate:mm_migrate_pages 88 145
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11830 22797
numa_hint_faults_local 11301 21539
numa_hit 90038 89308
numa_huge_pte_updates 0 0
numa_interleave 855 865
numa_local 89796 88955
numa_other 242 353
numa_pages_migrated 88 149
numa_pte_updates 12039 22930
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,049,153 2,195,628
migrations 11,405 11,179
faults 162,309 149,656
cache-misses 7,203,343 8,117,515
sched:sched_move_numa 22 49
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 1 5
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 1693 3577
numa_hint_faults_local 1669 3476
numa_hit 25177 26142
numa_huge_pte_updates 0 0
numa_interleave 194 358
numa_local 24993 26042
numa_other 184 100
numa_pages_migrated 1 5
numa_pte_updates 1577 3587
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 94,515,937 100,602,296
migrations 4,203,554 4,135,630
faults 832,697 789,256
cache-misses 226,248,698,331 226,160,621,058
sched:sched_move_numa 1,730 1,366
sched:sched_stick_numa 14 16
sched:sched_swap_numa 432 374
migrate:mm_migrate_pages 1,398 1,350
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 80079 47857
numa_hint_faults_local 68620 39768
numa_hit 241187 240165
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 241186 240165
numa_other 1 0
numa_pages_migrated 1347 1224
numa_pte_updates 80729 48354
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 63,704,961 58,515,496
migrations 573,404 564,845
faults 230,878 245,807
cache-misses 76,568,222,781 73,603,757,976
sched:sched_move_numa 509 996
sched:sched_stick_numa 31 10
sched:sched_swap_numa 182 193
migrate:mm_migrate_pages 541 646
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 8501 13422
numa_hint_faults_local 2960 5619
numa_hit 35526 36118
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 35526 36116
numa_other 0 2
numa_pages_migrated 539 616
numa_pte_updates 8433 13374
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-5-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:59 +00:00
|
|
|
if (!static_branch_likely(&sched_numa_balancing))
|
|
|
|
return;
|
|
|
|
|
sched/numa: Reset scan rate whenever task moves across nodes
Currently task scan rate is reset when NUMA balancer migrates the task
to a different node. If NUMA balancer initiates a swap, reset is only
applicable to the task that initiates the swap. Similarly no scan rate
reset is done if the task is migrated across nodes by traditional load
balancer.
Instead move the scan reset to the migrate_task_rq. This ensures the
task moved out of its preferred node, either gets back to its preferred
node quickly or finds a new preferred node. Doing so, would be fair to
all tasks migrating across nodes.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200668 203370 1.3465
1 321791 328431 2.06345
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 204848 206070 0.59654
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 188098 188386 0.153112
1 200351 201566 0.606436
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 58145.9 59157.4 1.73959
1 103798 105495 1.63491
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,912,183 13,825,492
migrations 1,155,931 1,152,509
faults 367,139 371,948
cache-misses 54,240,196,814 55,654,206,041
sched:sched_move_numa 1,571 1,856
sched:sched_stick_numa 9 4
sched:sched_swap_numa 463 428
migrate:mm_migrate_pages 703 898
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 50155 57146
numa_hint_faults_local 45264 51612
numa_hit 239652 238164
numa_huge_pte_updates 36 16
numa_interleave 68 63
numa_local 239576 238085
numa_other 76 79
numa_pages_migrated 680 883
numa_pte_updates 71146 67540
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,156,720 3,288,525
migrations 30,354 38,652
faults 97,261 111,678
cache-misses 12,400,026,826 12,111,197,376
sched:sched_move_numa 4 900
sched:sched_stick_numa 0 0
sched:sched_swap_numa 1 5
migrate:mm_migrate_pages 20 714
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 272 18572
numa_hint_faults_local 186 14850
numa_hit 71362 73197
numa_huge_pte_updates 0 11
numa_interleave 23 25
numa_local 71299 73138
numa_other 63 59
numa_pages_migrated 2 712
numa_pte_updates 0 24021
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,606,824 8,451,543
migrations 155,352 202,804
faults 301,409 310,024
cache-misses 157,759,224 253,522,507
sched:sched_move_numa 168 213
sched:sched_stick_numa 0 0
sched:sched_swap_numa 3 2
migrate:mm_migrate_pages 125 88
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 4650 11830
numa_hint_faults_local 3946 11301
numa_hit 90489 90038
numa_huge_pte_updates 0 0
numa_interleave 892 855
numa_local 90034 89796
numa_other 455 242
numa_pages_migrated 124 88
numa_pte_updates 4818 12039
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,113,167 2,049,153
migrations 10,533 11,405
faults 142,727 162,309
cache-misses 5,594,192 7,203,343
sched:sched_move_numa 10 22
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 6 1
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 744 1693
numa_hint_faults_local 584 1669
numa_hit 25551 25177
numa_huge_pte_updates 0 0
numa_interleave 263 194
numa_local 25302 24993
numa_other 249 184
numa_pages_migrated 6 1
numa_pte_updates 744 1577
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 101,227,352 94,515,937
migrations 4,151,829 4,203,554
faults 745,233 832,697
cache-misses 224,669,561,766 226,248,698,331
sched:sched_move_numa 617 1,730
sched:sched_stick_numa 2 14
sched:sched_swap_numa 187 432
migrate:mm_migrate_pages 316 1,398
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 24195 80079
numa_hint_faults_local 21639 68620
numa_hit 238331 241187
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 238331 241186
numa_other 0 1
numa_pages_migrated 204 1347
numa_pte_updates 24561 80729
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 62,738,978 63,704,961
migrations 562,702 573,404
faults 228,465 230,878
cache-misses 75,778,067,952 76,568,222,781
sched:sched_move_numa 648 509
sched:sched_stick_numa 13 31
sched:sched_swap_numa 137 182
migrate:mm_migrate_pages 733 541
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 10281 8501
numa_hint_faults_local 3242 2960
numa_hit 36338 35526
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 36338 35526
numa_other 0 0
numa_pages_migrated 706 539
numa_pte_updates 10176 8433
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-4-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:58 +00:00
|
|
|
if (!p->mm || !p->numa_faults || (p->flags & PF_EXITING))
|
|
|
|
return;
|
|
|
|
|
sched/numa: Limit the conditions where scan period is reset
migrate_task_rq_fair() resets the scan rate for NUMA balancing on every
cross-node migration. In the event of excessive load balancing due to
saturation, this may result in the scan rate being pegged at maximum and
further overloading the machine.
This patch only resets the scan if NUMA balancing is active, a preferred
node has been selected and the task is being migrated from the preferred
node as these are the most harmful. For example, a migration to the preferred
node does not justify a faster scan rate. Similarly, a migration between two
nodes that are not preferred is probably bouncing due to over-saturation of
the machine. In that case, scanning faster and trapping more NUMA faults
will further overload the machine.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 203370 205332 0.964744
1 328431 319785 -2.63252
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 206070 206585 0.249915
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 188386 189162 0.41192
1 201566 213760 6.04963
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 59157.4 58736.8 -0.710985
1 105495 105419 -0.0720413
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,825,492 14,285,708
migrations 1,152,509 1,180,621
faults 371,948 339,114
cache-misses 55,654,206,041 55,205,631,894
sched:sched_move_numa 1,856 843
sched:sched_stick_numa 4 6
sched:sched_swap_numa 428 219
migrate:mm_migrate_pages 898 365
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 57146 26907
numa_hint_faults_local 51612 24279
numa_hit 238164 239771
numa_huge_pte_updates 16 0
numa_interleave 63 68
numa_local 238085 239688
numa_other 79 83
numa_pages_migrated 883 363
numa_pte_updates 67540 27415
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,288,525 3,202,779
migrations 38,652 37,186
faults 111,678 106,076
cache-misses 12,111,197,376 12,024,873,744
sched:sched_move_numa 900 931
sched:sched_stick_numa 0 0
sched:sched_swap_numa 5 1
migrate:mm_migrate_pages 714 637
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 18572 17409
numa_hint_faults_local 14850 14367
numa_hit 73197 73953
numa_huge_pte_updates 11 20
numa_interleave 25 25
numa_local 73138 73892
numa_other 59 61
numa_pages_migrated 712 668
numa_pte_updates 24021 27276
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,451,543 8,474,013
migrations 202,804 254,934
faults 310,024 320,506
cache-misses 253,522,507 110,580,458
sched:sched_move_numa 213 725
sched:sched_stick_numa 0 0
sched:sched_swap_numa 2 7
migrate:mm_migrate_pages 88 145
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11830 22797
numa_hint_faults_local 11301 21539
numa_hit 90038 89308
numa_huge_pte_updates 0 0
numa_interleave 855 865
numa_local 89796 88955
numa_other 242 353
numa_pages_migrated 88 149
numa_pte_updates 12039 22930
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,049,153 2,195,628
migrations 11,405 11,179
faults 162,309 149,656
cache-misses 7,203,343 8,117,515
sched:sched_move_numa 22 49
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 1 5
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 1693 3577
numa_hint_faults_local 1669 3476
numa_hit 25177 26142
numa_huge_pte_updates 0 0
numa_interleave 194 358
numa_local 24993 26042
numa_other 184 100
numa_pages_migrated 1 5
numa_pte_updates 1577 3587
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 94,515,937 100,602,296
migrations 4,203,554 4,135,630
faults 832,697 789,256
cache-misses 226,248,698,331 226,160,621,058
sched:sched_move_numa 1,730 1,366
sched:sched_stick_numa 14 16
sched:sched_swap_numa 432 374
migrate:mm_migrate_pages 1,398 1,350
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 80079 47857
numa_hint_faults_local 68620 39768
numa_hit 241187 240165
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 241186 240165
numa_other 1 0
numa_pages_migrated 1347 1224
numa_pte_updates 80729 48354
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 63,704,961 58,515,496
migrations 573,404 564,845
faults 230,878 245,807
cache-misses 76,568,222,781 73,603,757,976
sched:sched_move_numa 509 996
sched:sched_stick_numa 31 10
sched:sched_swap_numa 182 193
migrate:mm_migrate_pages 541 646
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 8501 13422
numa_hint_faults_local 2960 5619
numa_hit 35526 36118
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 35526 36116
numa_other 0 2
numa_pages_migrated 539 616
numa_pte_updates 8433 13374
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-5-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:59 +00:00
|
|
|
if (src_nid == dst_nid)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allow resets if faults have been trapped before one scan
|
|
|
|
* has completed. This is most likely due to a new task that
|
|
|
|
* is pulled cross-node due to wakeups or load balancing.
|
|
|
|
*/
|
|
|
|
if (p->numa_scan_seq) {
|
|
|
|
/*
|
|
|
|
* Avoid scan adjustments if moving to the preferred
|
|
|
|
* node or if the task was not previously running on
|
|
|
|
* the preferred node.
|
|
|
|
*/
|
|
|
|
if (dst_nid == p->numa_preferred_nid ||
|
2019-03-05 23:42:58 +00:00
|
|
|
(p->numa_preferred_nid != NUMA_NO_NODE &&
|
|
|
|
src_nid != p->numa_preferred_nid))
|
sched/numa: Limit the conditions where scan period is reset
migrate_task_rq_fair() resets the scan rate for NUMA balancing on every
cross-node migration. In the event of excessive load balancing due to
saturation, this may result in the scan rate being pegged at maximum and
further overloading the machine.
This patch only resets the scan if NUMA balancing is active, a preferred
node has been selected and the task is being migrated from the preferred
node as these are the most harmful. For example, a migration to the preferred
node does not justify a faster scan rate. Similarly, a migration between two
nodes that are not preferred is probably bouncing due to over-saturation of
the machine. In that case, scanning faster and trapping more NUMA faults
will further overload the machine.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 203370 205332 0.964744
1 328431 319785 -2.63252
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 206070 206585 0.249915
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 188386 189162 0.41192
1 201566 213760 6.04963
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 59157.4 58736.8 -0.710985
1 105495 105419 -0.0720413
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,825,492 14,285,708
migrations 1,152,509 1,180,621
faults 371,948 339,114
cache-misses 55,654,206,041 55,205,631,894
sched:sched_move_numa 1,856 843
sched:sched_stick_numa 4 6
sched:sched_swap_numa 428 219
migrate:mm_migrate_pages 898 365
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 57146 26907
numa_hint_faults_local 51612 24279
numa_hit 238164 239771
numa_huge_pte_updates 16 0
numa_interleave 63 68
numa_local 238085 239688
numa_other 79 83
numa_pages_migrated 883 363
numa_pte_updates 67540 27415
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,288,525 3,202,779
migrations 38,652 37,186
faults 111,678 106,076
cache-misses 12,111,197,376 12,024,873,744
sched:sched_move_numa 900 931
sched:sched_stick_numa 0 0
sched:sched_swap_numa 5 1
migrate:mm_migrate_pages 714 637
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 18572 17409
numa_hint_faults_local 14850 14367
numa_hit 73197 73953
numa_huge_pte_updates 11 20
numa_interleave 25 25
numa_local 73138 73892
numa_other 59 61
numa_pages_migrated 712 668
numa_pte_updates 24021 27276
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,451,543 8,474,013
migrations 202,804 254,934
faults 310,024 320,506
cache-misses 253,522,507 110,580,458
sched:sched_move_numa 213 725
sched:sched_stick_numa 0 0
sched:sched_swap_numa 2 7
migrate:mm_migrate_pages 88 145
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 11830 22797
numa_hint_faults_local 11301 21539
numa_hit 90038 89308
numa_huge_pte_updates 0 0
numa_interleave 855 865
numa_local 89796 88955
numa_other 242 353
numa_pages_migrated 88 149
numa_pte_updates 12039 22930
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,049,153 2,195,628
migrations 11,405 11,179
faults 162,309 149,656
cache-misses 7,203,343 8,117,515
sched:sched_move_numa 22 49
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 1 5
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 1693 3577
numa_hint_faults_local 1669 3476
numa_hit 25177 26142
numa_huge_pte_updates 0 0
numa_interleave 194 358
numa_local 24993 26042
numa_other 184 100
numa_pages_migrated 1 5
numa_pte_updates 1577 3587
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 94,515,937 100,602,296
migrations 4,203,554 4,135,630
faults 832,697 789,256
cache-misses 226,248,698,331 226,160,621,058
sched:sched_move_numa 1,730 1,366
sched:sched_stick_numa 14 16
sched:sched_swap_numa 432 374
migrate:mm_migrate_pages 1,398 1,350
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 80079 47857
numa_hint_faults_local 68620 39768
numa_hit 241187 240165
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 241186 240165
numa_other 1 0
numa_pages_migrated 1347 1224
numa_pte_updates 80729 48354
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 63,704,961 58,515,496
migrations 573,404 564,845
faults 230,878 245,807
cache-misses 76,568,222,781 73,603,757,976
sched:sched_move_numa 509 996
sched:sched_stick_numa 31 10
sched:sched_swap_numa 182 193
migrate:mm_migrate_pages 541 646
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 8501 13422
numa_hint_faults_local 2960 5619
numa_hit 35526 36118
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 35526 36116
numa_other 0 2
numa_pages_migrated 539 616
numa_pte_updates 8433 13374
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-5-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:59 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
p->numa_scan_period = task_scan_start(p);
|
sched/numa: Reset scan rate whenever task moves across nodes
Currently task scan rate is reset when NUMA balancer migrates the task
to a different node. If NUMA balancer initiates a swap, reset is only
applicable to the task that initiates the swap. Similarly no scan rate
reset is done if the task is migrated across nodes by traditional load
balancer.
Instead move the scan reset to the migrate_task_rq. This ensures the
task moved out of its preferred node, either gets back to its preferred
node quickly or finds a new preferred node. Doing so, would be fair to
all tasks migrating across nodes.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200668 203370 1.3465
1 321791 328431 2.06345
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 204848 206070 0.59654
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 188098 188386 0.153112
1 200351 201566 0.606436
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 58145.9 59157.4 1.73959
1 103798 105495 1.63491
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,912,183 13,825,492
migrations 1,155,931 1,152,509
faults 367,139 371,948
cache-misses 54,240,196,814 55,654,206,041
sched:sched_move_numa 1,571 1,856
sched:sched_stick_numa 9 4
sched:sched_swap_numa 463 428
migrate:mm_migrate_pages 703 898
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 50155 57146
numa_hint_faults_local 45264 51612
numa_hit 239652 238164
numa_huge_pte_updates 36 16
numa_interleave 68 63
numa_local 239576 238085
numa_other 76 79
numa_pages_migrated 680 883
numa_pte_updates 71146 67540
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,156,720 3,288,525
migrations 30,354 38,652
faults 97,261 111,678
cache-misses 12,400,026,826 12,111,197,376
sched:sched_move_numa 4 900
sched:sched_stick_numa 0 0
sched:sched_swap_numa 1 5
migrate:mm_migrate_pages 20 714
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 272 18572
numa_hint_faults_local 186 14850
numa_hit 71362 73197
numa_huge_pte_updates 0 11
numa_interleave 23 25
numa_local 71299 73138
numa_other 63 59
numa_pages_migrated 2 712
numa_pte_updates 0 24021
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,606,824 8,451,543
migrations 155,352 202,804
faults 301,409 310,024
cache-misses 157,759,224 253,522,507
sched:sched_move_numa 168 213
sched:sched_stick_numa 0 0
sched:sched_swap_numa 3 2
migrate:mm_migrate_pages 125 88
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 4650 11830
numa_hint_faults_local 3946 11301
numa_hit 90489 90038
numa_huge_pte_updates 0 0
numa_interleave 892 855
numa_local 90034 89796
numa_other 455 242
numa_pages_migrated 124 88
numa_pte_updates 4818 12039
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,113,167 2,049,153
migrations 10,533 11,405
faults 142,727 162,309
cache-misses 5,594,192 7,203,343
sched:sched_move_numa 10 22
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 6 1
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 744 1693
numa_hint_faults_local 584 1669
numa_hit 25551 25177
numa_huge_pte_updates 0 0
numa_interleave 263 194
numa_local 25302 24993
numa_other 249 184
numa_pages_migrated 6 1
numa_pte_updates 744 1577
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 101,227,352 94,515,937
migrations 4,151,829 4,203,554
faults 745,233 832,697
cache-misses 224,669,561,766 226,248,698,331
sched:sched_move_numa 617 1,730
sched:sched_stick_numa 2 14
sched:sched_swap_numa 187 432
migrate:mm_migrate_pages 316 1,398
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 24195 80079
numa_hint_faults_local 21639 68620
numa_hit 238331 241187
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 238331 241186
numa_other 0 1
numa_pages_migrated 204 1347
numa_pte_updates 24561 80729
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 62,738,978 63,704,961
migrations 562,702 573,404
faults 228,465 230,878
cache-misses 75,778,067,952 76,568,222,781
sched:sched_move_numa 648 509
sched:sched_stick_numa 13 31
sched:sched_swap_numa 137 182
migrate:mm_migrate_pages 733 541
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 10281 8501
numa_hint_faults_local 3242 2960
numa_hit 36338 35526
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 36338 35526
numa_other 0 0
numa_pages_migrated 706 539
numa_pte_updates 10176 8433
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-4-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:58 +00:00
|
|
|
}
|
|
|
|
|
2012-10-25 12:16:43 +00:00
|
|
|
#else
|
|
|
|
static void task_tick_numa(struct rq *rq, struct task_struct *curr)
|
|
|
|
{
|
|
|
|
}
|
2013-10-07 10:29:33 +00:00
|
|
|
|
|
|
|
static inline void account_numa_enqueue(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void account_numa_dequeue(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
}
|
2017-06-23 16:55:29 +00:00
|
|
|
|
sched/numa: Reset scan rate whenever task moves across nodes
Currently task scan rate is reset when NUMA balancer migrates the task
to a different node. If NUMA balancer initiates a swap, reset is only
applicable to the task that initiates the swap. Similarly no scan rate
reset is done if the task is migrated across nodes by traditional load
balancer.
Instead move the scan reset to the migrate_task_rq. This ensures the
task moved out of its preferred node, either gets back to its preferred
node quickly or finds a new preferred node. Doing so, would be fair to
all tasks migrating across nodes.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200668 203370 1.3465
1 321791 328431 2.06345
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 204848 206070 0.59654
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 188098 188386 0.153112
1 200351 201566 0.606436
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 58145.9 59157.4 1.73959
1 103798 105495 1.63491
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,912,183 13,825,492
migrations 1,155,931 1,152,509
faults 367,139 371,948
cache-misses 54,240,196,814 55,654,206,041
sched:sched_move_numa 1,571 1,856
sched:sched_stick_numa 9 4
sched:sched_swap_numa 463 428
migrate:mm_migrate_pages 703 898
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 50155 57146
numa_hint_faults_local 45264 51612
numa_hit 239652 238164
numa_huge_pte_updates 36 16
numa_interleave 68 63
numa_local 239576 238085
numa_other 76 79
numa_pages_migrated 680 883
numa_pte_updates 71146 67540
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,156,720 3,288,525
migrations 30,354 38,652
faults 97,261 111,678
cache-misses 12,400,026,826 12,111,197,376
sched:sched_move_numa 4 900
sched:sched_stick_numa 0 0
sched:sched_swap_numa 1 5
migrate:mm_migrate_pages 20 714
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 272 18572
numa_hint_faults_local 186 14850
numa_hit 71362 73197
numa_huge_pte_updates 0 11
numa_interleave 23 25
numa_local 71299 73138
numa_other 63 59
numa_pages_migrated 2 712
numa_pte_updates 0 24021
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,606,824 8,451,543
migrations 155,352 202,804
faults 301,409 310,024
cache-misses 157,759,224 253,522,507
sched:sched_move_numa 168 213
sched:sched_stick_numa 0 0
sched:sched_swap_numa 3 2
migrate:mm_migrate_pages 125 88
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 4650 11830
numa_hint_faults_local 3946 11301
numa_hit 90489 90038
numa_huge_pte_updates 0 0
numa_interleave 892 855
numa_local 90034 89796
numa_other 455 242
numa_pages_migrated 124 88
numa_pte_updates 4818 12039
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,113,167 2,049,153
migrations 10,533 11,405
faults 142,727 162,309
cache-misses 5,594,192 7,203,343
sched:sched_move_numa 10 22
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 6 1
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 744 1693
numa_hint_faults_local 584 1669
numa_hit 25551 25177
numa_huge_pte_updates 0 0
numa_interleave 263 194
numa_local 25302 24993
numa_other 249 184
numa_pages_migrated 6 1
numa_pte_updates 744 1577
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 101,227,352 94,515,937
migrations 4,151,829 4,203,554
faults 745,233 832,697
cache-misses 224,669,561,766 226,248,698,331
sched:sched_move_numa 617 1,730
sched:sched_stick_numa 2 14
sched:sched_swap_numa 187 432
migrate:mm_migrate_pages 316 1,398
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 24195 80079
numa_hint_faults_local 21639 68620
numa_hit 238331 241187
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 238331 241186
numa_other 0 1
numa_pages_migrated 204 1347
numa_pte_updates 24561 80729
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 62,738,978 63,704,961
migrations 562,702 573,404
faults 228,465 230,878
cache-misses 75,778,067,952 76,568,222,781
sched:sched_move_numa 648 509
sched:sched_stick_numa 13 31
sched:sched_swap_numa 137 182
migrate:mm_migrate_pages 733 541
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 10281 8501
numa_hint_faults_local 3242 2960
numa_hit 36338 35526
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 36338 35526
numa_other 0 0
numa_pages_migrated 706 539
numa_pte_updates 10176 8433
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-4-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:58 +00:00
|
|
|
static inline void update_scan_period(struct task_struct *p, int new_cpu)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2012-10-25 12:16:43 +00:00
|
|
|
#endif /* CONFIG_NUMA_BALANCING */
|
|
|
|
|
2007-10-15 15:00:07 +00:00
|
|
|
static void
|
|
|
|
account_entity_enqueue(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
|
|
|
update_load_add(&cfs_rq->load, se->load.weight);
|
2012-02-20 20:49:09 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2013-10-07 10:29:33 +00:00
|
|
|
if (entity_is_task(se)) {
|
|
|
|
struct rq *rq = rq_of(cfs_rq);
|
|
|
|
|
|
|
|
account_numa_enqueue(rq, task_of(se));
|
|
|
|
list_add(&se->group_node, &rq->cfs_tasks);
|
|
|
|
}
|
2012-02-20 20:49:09 +00:00
|
|
|
#endif
|
2007-10-15 15:00:07 +00:00
|
|
|
cfs_rq->nr_running++;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
account_entity_dequeue(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
|
|
|
update_load_sub(&cfs_rq->load, se->load.weight);
|
2016-02-01 22:47:59 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2013-10-07 10:29:33 +00:00
|
|
|
if (entity_is_task(se)) {
|
|
|
|
account_numa_dequeue(rq_of(cfs_rq), task_of(se));
|
2008-09-25 04:23:54 +00:00
|
|
|
list_del_init(&se->group_node);
|
2013-10-07 10:29:33 +00:00
|
|
|
}
|
2016-02-01 22:47:59 +00:00
|
|
|
#endif
|
2007-10-15 15:00:07 +00:00
|
|
|
cfs_rq->nr_running--;
|
|
|
|
}
|
|
|
|
|
2017-08-24 15:45:35 +00:00
|
|
|
/*
|
|
|
|
* Signed add and clamp on underflow.
|
|
|
|
*
|
|
|
|
* Explicitly do a load-store to ensure the intermediate value never hits
|
|
|
|
* memory. This allows lockless observations without ever seeing the negative
|
|
|
|
* values.
|
|
|
|
*/
|
|
|
|
#define add_positive(_ptr, _val) do { \
|
|
|
|
typeof(_ptr) ptr = (_ptr); \
|
|
|
|
typeof(_val) val = (_val); \
|
|
|
|
typeof(*ptr) res, var = READ_ONCE(*ptr); \
|
|
|
|
\
|
|
|
|
res = var + val; \
|
|
|
|
\
|
|
|
|
if (val < 0 && res > var) \
|
|
|
|
res = 0; \
|
|
|
|
\
|
|
|
|
WRITE_ONCE(*ptr, res); \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Unsigned subtract and clamp on underflow.
|
|
|
|
*
|
|
|
|
* Explicitly do a load-store to ensure the intermediate value never hits
|
|
|
|
* memory. This allows lockless observations without ever seeing the negative
|
|
|
|
* values.
|
|
|
|
*/
|
|
|
|
#define sub_positive(_ptr, _val) do { \
|
|
|
|
typeof(_ptr) ptr = (_ptr); \
|
|
|
|
typeof(*ptr) val = (_val); \
|
|
|
|
typeof(*ptr) res, var = READ_ONCE(*ptr); \
|
|
|
|
res = var - val; \
|
|
|
|
if (res > var) \
|
|
|
|
res = 0; \
|
|
|
|
WRITE_ONCE(*ptr, res); \
|
|
|
|
} while (0)
|
|
|
|
|
2018-11-05 14:54:00 +00:00
|
|
|
/*
|
|
|
|
* Remove and clamp on negative, from a local variable.
|
|
|
|
*
|
|
|
|
* A variant of sub_positive(), which does not use explicit load-store
|
|
|
|
* and is thus optimized for local variable updates.
|
|
|
|
*/
|
|
|
|
#define lsub_positive(_ptr, _val) do { \
|
|
|
|
typeof(_ptr) ptr = (_ptr); \
|
|
|
|
*ptr -= min_t(typeof(*ptr), *ptr, _val); \
|
|
|
|
} while (0)
|
|
|
|
|
2017-08-24 15:45:35 +00:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
static inline void
|
|
|
|
enqueue_runnable_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
2017-05-06 13:59:54 +00:00
|
|
|
cfs_rq->runnable_weight += se->runnable_weight;
|
|
|
|
|
|
|
|
cfs_rq->avg.runnable_load_avg += se->avg.runnable_load_avg;
|
|
|
|
cfs_rq->avg.runnable_load_sum += se_runnable(se) * se->avg.runnable_load_sum;
|
2017-08-24 15:45:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
dequeue_runnable_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
2017-05-06 13:59:54 +00:00
|
|
|
cfs_rq->runnable_weight -= se->runnable_weight;
|
|
|
|
|
|
|
|
sub_positive(&cfs_rq->avg.runnable_load_avg, se->avg.runnable_load_avg);
|
|
|
|
sub_positive(&cfs_rq->avg.runnable_load_sum,
|
|
|
|
se_runnable(se) * se->avg.runnable_load_sum);
|
2017-08-24 15:45:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
enqueue_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
|
|
|
cfs_rq->avg.load_avg += se->avg.load_avg;
|
|
|
|
cfs_rq->avg.load_sum += se_weight(se) * se->avg.load_sum;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
dequeue_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
|
|
|
sub_positive(&cfs_rq->avg.load_avg, se->avg.load_avg);
|
|
|
|
sub_positive(&cfs_rq->avg.load_sum, se_weight(se) * se->avg.load_sum);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void
|
|
|
|
enqueue_runnable_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) { }
|
|
|
|
static inline void
|
|
|
|
dequeue_runnable_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) { }
|
|
|
|
static inline void
|
|
|
|
enqueue_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) { }
|
|
|
|
static inline void
|
|
|
|
dequeue_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) { }
|
|
|
|
#endif
|
|
|
|
|
2017-05-17 09:50:45 +00:00
|
|
|
static void reweight_entity(struct cfs_rq *cfs_rq, struct sched_entity *se,
|
2017-05-06 13:59:54 +00:00
|
|
|
unsigned long weight, unsigned long runnable)
|
2017-05-17 09:50:45 +00:00
|
|
|
{
|
|
|
|
if (se->on_rq) {
|
|
|
|
/* commit outstanding execution time */
|
|
|
|
if (cfs_rq->curr == se)
|
|
|
|
update_curr(cfs_rq);
|
|
|
|
account_entity_dequeue(cfs_rq, se);
|
|
|
|
dequeue_runnable_load_avg(cfs_rq, se);
|
|
|
|
}
|
|
|
|
dequeue_load_avg(cfs_rq, se);
|
|
|
|
|
2017-05-06 13:59:54 +00:00
|
|
|
se->runnable_weight = runnable;
|
2017-05-17 09:50:45 +00:00
|
|
|
update_load_set(&se->load, weight);
|
|
|
|
|
|
|
|
#ifdef CONFIG_SMP
|
2017-05-06 13:59:54 +00:00
|
|
|
do {
|
|
|
|
u32 divider = LOAD_AVG_MAX - 1024 + se->avg.period_contrib;
|
|
|
|
|
|
|
|
se->avg.load_avg = div_u64(se_weight(se) * se->avg.load_sum, divider);
|
|
|
|
se->avg.runnable_load_avg =
|
|
|
|
div_u64(se_runnable(se) * se->avg.runnable_load_sum, divider);
|
|
|
|
} while (0);
|
2017-05-17 09:50:45 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
enqueue_load_avg(cfs_rq, se);
|
|
|
|
if (se->on_rq) {
|
|
|
|
account_entity_enqueue(cfs_rq, se);
|
|
|
|
enqueue_runnable_load_avg(cfs_rq, se);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void reweight_task(struct task_struct *p, int prio)
|
|
|
|
{
|
|
|
|
struct sched_entity *se = &p->se;
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
|
|
|
struct load_weight *load = &se->load;
|
|
|
|
unsigned long weight = scale_load(sched_prio_to_weight[prio]);
|
|
|
|
|
2017-05-06 13:59:54 +00:00
|
|
|
reweight_entity(cfs_rq, se, weight, weight);
|
2017-05-17 09:50:45 +00:00
|
|
|
load->inv_weight = sched_prio_to_wmult[prio];
|
|
|
|
}
|
|
|
|
|
2011-01-24 07:33:52 +00:00
|
|
|
#ifdef CONFIG_FAIR_GROUP_SCHED
|
2018-02-13 08:59:42 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2017-05-09 09:04:07 +00:00
|
|
|
/*
|
|
|
|
* All this does is approximate the hierarchical proportion which includes that
|
|
|
|
* global sum we all love to hate.
|
|
|
|
*
|
|
|
|
* That is, the weight of a group entity, is the proportional share of the
|
|
|
|
* group weight based on the group runqueue weights. That is:
|
|
|
|
*
|
|
|
|
* tg->weight * grq->load.weight
|
|
|
|
* ge->load.weight = ----------------------------- (1)
|
|
|
|
* \Sum grq->load.weight
|
|
|
|
*
|
|
|
|
* Now, because computing that sum is prohibitively expensive to compute (been
|
|
|
|
* there, done that) we approximate it with this average stuff. The average
|
|
|
|
* moves slower and therefore the approximation is cheaper and more stable.
|
|
|
|
*
|
|
|
|
* So instead of the above, we substitute:
|
|
|
|
*
|
|
|
|
* grq->load.weight -> grq->avg.load_avg (2)
|
|
|
|
*
|
|
|
|
* which yields the following:
|
|
|
|
*
|
|
|
|
* tg->weight * grq->avg.load_avg
|
|
|
|
* ge->load.weight = ------------------------------ (3)
|
|
|
|
* tg->load_avg
|
|
|
|
*
|
|
|
|
* Where: tg->load_avg ~= \Sum grq->avg.load_avg
|
|
|
|
*
|
|
|
|
* That is shares_avg, and it is right (given the approximation (2)).
|
|
|
|
*
|
|
|
|
* The problem with it is that because the average is slow -- it was designed
|
|
|
|
* to be exactly that of course -- this leads to transients in boundary
|
|
|
|
* conditions. In specific, the case where the group was idle and we start the
|
|
|
|
* one task. It takes time for our CPU's grq->avg.load_avg to build up,
|
|
|
|
* yielding bad latency etc..
|
|
|
|
*
|
|
|
|
* Now, in that special case (1) reduces to:
|
|
|
|
*
|
|
|
|
* tg->weight * grq->load.weight
|
2017-08-24 11:06:35 +00:00
|
|
|
* ge->load.weight = ----------------------------- = tg->weight (4)
|
2017-05-09 09:04:07 +00:00
|
|
|
* grp->load.weight
|
|
|
|
*
|
|
|
|
* That is, the sum collapses because all other CPUs are idle; the UP scenario.
|
|
|
|
*
|
|
|
|
* So what we do is modify our approximation (3) to approach (4) in the (near)
|
|
|
|
* UP case, like:
|
|
|
|
*
|
|
|
|
* ge->load.weight =
|
|
|
|
*
|
|
|
|
* tg->weight * grq->load.weight
|
|
|
|
* --------------------------------------------------- (5)
|
|
|
|
* tg->load_avg - grq->avg.load_avg + grq->load.weight
|
|
|
|
*
|
2017-08-24 11:06:35 +00:00
|
|
|
* But because grq->load.weight can drop to 0, resulting in a divide by zero,
|
|
|
|
* we need to use grq->avg.load_avg as its lower bound, which then gives:
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* tg->weight * grq->load.weight
|
|
|
|
* ge->load.weight = ----------------------------- (6)
|
|
|
|
* tg_load_avg'
|
|
|
|
*
|
|
|
|
* Where:
|
|
|
|
*
|
|
|
|
* tg_load_avg' = tg->load_avg - grq->avg.load_avg +
|
|
|
|
* max(grq->load.weight, grq->avg.load_avg)
|
2017-05-09 09:04:07 +00:00
|
|
|
*
|
|
|
|
* And that is shares_weight and is icky. In the (near) UP case it approaches
|
|
|
|
* (4) while in the normal case it approaches (3). It consistently
|
|
|
|
* overestimates the ge->load.weight and therefore:
|
|
|
|
*
|
|
|
|
* \Sum ge->load.weight >= tg->weight
|
|
|
|
*
|
|
|
|
* hence icky!
|
|
|
|
*/
|
2017-08-03 15:13:39 +00:00
|
|
|
static long calc_group_shares(struct cfs_rq *cfs_rq)
|
2011-10-13 14:52:28 +00:00
|
|
|
{
|
2017-05-06 14:03:17 +00:00
|
|
|
long tg_weight, tg_shares, load, shares;
|
|
|
|
struct task_group *tg = cfs_rq->tg;
|
|
|
|
|
|
|
|
tg_shares = READ_ONCE(tg->shares);
|
2011-10-13 14:52:28 +00:00
|
|
|
|
2017-05-11 16:16:06 +00:00
|
|
|
load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg);
|
2011-10-13 14:52:28 +00:00
|
|
|
|
2016-06-24 14:11:02 +00:00
|
|
|
tg_weight = atomic_long_read(&tg->load_avg);
|
2011-01-24 07:33:52 +00:00
|
|
|
|
2016-06-24 14:11:02 +00:00
|
|
|
/* Ensure tg_weight >= load */
|
|
|
|
tg_weight -= cfs_rq->tg_load_avg_contrib;
|
|
|
|
tg_weight += load;
|
2011-01-24 07:33:52 +00:00
|
|
|
|
2017-05-06 14:03:17 +00:00
|
|
|
shares = (tg_shares * load);
|
2011-10-13 14:52:28 +00:00
|
|
|
if (tg_weight)
|
|
|
|
shares /= tg_weight;
|
2011-01-24 07:33:52 +00:00
|
|
|
|
2017-01-11 11:29:47 +00:00
|
|
|
/*
|
|
|
|
* MIN_SHARES has to be unscaled here to support per-CPU partitioning
|
|
|
|
* of a group with small tg->shares value. It is a floor value which is
|
|
|
|
* assigned as a minimum load.weight to the sched_entity representing
|
|
|
|
* the group on a CPU.
|
|
|
|
*
|
|
|
|
* E.g. on 64-bit for a group with tg->shares of scale_load(15)=15*1024
|
|
|
|
* on an 8-core system with 8 tasks each runnable on one CPU shares has
|
|
|
|
* to be 15*1024*1/8=1920 instead of scale_load(MIN_SHARES)=2*1024. In
|
|
|
|
* case no task is runnable on a CPU MIN_SHARES=2 should be returned
|
|
|
|
* instead of 0.
|
|
|
|
*/
|
2017-05-06 14:03:17 +00:00
|
|
|
return clamp_t(long, shares, MIN_SHARES, tg_shares);
|
2011-01-24 07:33:52 +00:00
|
|
|
}
|
2017-08-03 15:13:39 +00:00
|
|
|
|
|
|
|
/*
|
2017-08-24 11:06:35 +00:00
|
|
|
* This calculates the effective runnable weight for a group entity based on
|
|
|
|
* the group entity weight calculated above.
|
|
|
|
*
|
|
|
|
* Because of the above approximation (2), our group entity weight is
|
|
|
|
* an load_avg based ratio (3). This means that it includes blocked load and
|
|
|
|
* does not represent the runnable weight.
|
|
|
|
*
|
|
|
|
* Approximate the group entity's runnable weight per ratio from the group
|
|
|
|
* runqueue:
|
|
|
|
*
|
|
|
|
* grq->avg.runnable_load_avg
|
|
|
|
* ge->runnable_weight = ge->load.weight * -------------------------- (7)
|
|
|
|
* grq->avg.load_avg
|
|
|
|
*
|
|
|
|
* However, analogous to above, since the avg numbers are slow, this leads to
|
|
|
|
* transients in the from-idle case. Instead we use:
|
|
|
|
*
|
|
|
|
* ge->runnable_weight = ge->load.weight *
|
|
|
|
*
|
|
|
|
* max(grq->avg.runnable_load_avg, grq->runnable_weight)
|
|
|
|
* ----------------------------------------------------- (8)
|
|
|
|
* max(grq->avg.load_avg, grq->load.weight)
|
|
|
|
*
|
|
|
|
* Where these max() serve both to use the 'instant' values to fix the slow
|
|
|
|
* from-idle and avoid the /0 on to-idle, similar to (6).
|
2017-08-03 15:13:39 +00:00
|
|
|
*/
|
|
|
|
static long calc_group_runnable(struct cfs_rq *cfs_rq, long shares)
|
|
|
|
{
|
2017-08-24 11:06:35 +00:00
|
|
|
long runnable, load_avg;
|
|
|
|
|
|
|
|
load_avg = max(cfs_rq->avg.load_avg,
|
|
|
|
scale_load_down(cfs_rq->load.weight));
|
|
|
|
|
|
|
|
runnable = max(cfs_rq->avg.runnable_load_avg,
|
|
|
|
scale_load_down(cfs_rq->runnable_weight));
|
2017-08-03 15:13:39 +00:00
|
|
|
|
|
|
|
runnable *= shares;
|
|
|
|
if (load_avg)
|
|
|
|
runnable /= load_avg;
|
2017-08-24 11:06:35 +00:00
|
|
|
|
2017-08-03 15:13:39 +00:00
|
|
|
return clamp_t(long, runnable, MIN_SHARES, shares);
|
|
|
|
}
|
2018-02-13 08:59:42 +00:00
|
|
|
#endif /* CONFIG_SMP */
|
2016-06-24 14:11:02 +00:00
|
|
|
|
2012-10-04 11:18:31 +00:00
|
|
|
static inline int throttled_hierarchy(struct cfs_rq *cfs_rq);
|
|
|
|
|
2017-05-06 13:59:54 +00:00
|
|
|
/*
|
|
|
|
* Recomputes the group entity based on the current state of its group
|
|
|
|
* runqueue.
|
|
|
|
*/
|
|
|
|
static void update_cfs_group(struct sched_entity *se)
|
2010-11-15 23:47:00 +00:00
|
|
|
{
|
2017-05-06 13:59:54 +00:00
|
|
|
struct cfs_rq *gcfs_rq = group_cfs_rq(se);
|
|
|
|
long shares, runnable;
|
2010-11-15 23:47:00 +00:00
|
|
|
|
2017-05-06 13:59:54 +00:00
|
|
|
if (!gcfs_rq)
|
2016-12-21 15:50:26 +00:00
|
|
|
return;
|
|
|
|
|
2017-05-06 13:59:54 +00:00
|
|
|
if (throttled_hierarchy(gcfs_rq))
|
2010-11-15 23:47:00 +00:00
|
|
|
return;
|
2016-12-21 15:50:26 +00:00
|
|
|
|
2011-01-24 07:33:52 +00:00
|
|
|
#ifndef CONFIG_SMP
|
2017-05-06 13:59:54 +00:00
|
|
|
runnable = shares = READ_ONCE(gcfs_rq->tg->shares);
|
2017-05-06 14:03:17 +00:00
|
|
|
|
|
|
|
if (likely(se->load.weight == shares))
|
2011-01-24 07:33:52 +00:00
|
|
|
return;
|
2017-05-06 14:03:17 +00:00
|
|
|
#else
|
2017-08-03 15:13:39 +00:00
|
|
|
shares = calc_group_shares(gcfs_rq);
|
|
|
|
runnable = calc_group_runnable(gcfs_rq, shares);
|
2011-01-24 07:33:52 +00:00
|
|
|
#endif
|
2010-11-15 23:47:00 +00:00
|
|
|
|
2017-05-06 13:59:54 +00:00
|
|
|
reweight_entity(cfs_rq_of(se), se, shares, runnable);
|
2010-11-15 23:47:00 +00:00
|
|
|
}
|
2016-12-21 15:50:26 +00:00
|
|
|
|
2010-11-15 23:47:00 +00:00
|
|
|
#else /* CONFIG_FAIR_GROUP_SCHED */
|
2017-05-06 13:59:54 +00:00
|
|
|
static inline void update_cfs_group(struct sched_entity *se)
|
2010-11-15 23:47:00 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_FAIR_GROUP_SCHED */
|
|
|
|
|
2018-02-02 09:27:00 +00:00
|
|
|
static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq, int flags)
|
2017-05-24 05:29:52 +00:00
|
|
|
{
|
Power management updates for v4.14-rc1
- Drop the P-state selection algorithm based on a PID controller
from intel_pstate and make it use the same P-state selection
method (based on the CPU load) for all types of systems in the
active mode (Rafael Wysocki, Srinivas Pandruvada).
- Rework the cpufreq core and governors to make it possible to
take cross-CPU utilization updates into account and modify the
schedutil governor to actually do so (Viresh Kumar).
- Clean up the handling of transition latency information in the
cpufreq core and untangle it from the information on which drivers
cannot do dynamic frequency switching (Viresh Kumar).
- Add support for new SoCs (MT2701/MT7623 and MT7622) to the
mediatek cpufreq driver and update its DT bindings (Sean Wang).
- Modify the cpufreq dt-platdev driver to autimatically create
cpufreq devices for the new (v2) Operating Performance Points
(OPP) DT bindings and update its whitelist of supported systems
(Viresh Kumar, Shubhrajyoti Datta, Marc Gonzalez, Khiem Nguyen,
Finley Xiao).
- Add support for Ux500 to the cpufreq-dt driver and drop the
obsolete dbx500 cpufreq driver (Linus Walleij, Arnd Bergmann).
- Add new SoC (R8A7795) support to the cpufreq rcar driver (Khiem
Nguyen).
- Fix and clean up assorted issues in the cpufreq drivers and core
(Arvind Yadav, Christophe Jaillet, Colin Ian King, Gustavo Silva,
Julia Lawall, Leonard Crestez, Rob Herring, Sudeep Holla).
- Update the IO-wait boost handling in the schedutil governor to
make it less aggressive (Joel Fernandes).
- Rework system suspend diagnostics to make it print fewer messages
to the kernel log by default, add a sysfs knob to allow more
suspend-related messages to be printed and add Low Power S0 Idle
constraints checks to the ACPI suspend-to-idle code (Rafael
Wysocki, Srinivas Pandruvada).
- Prefer suspend-to-idle over S3 on ACPI-based systems with the
ACPI_FADT_LOW_POWER_S0 flag set and the Low Power Idle S0 _DSM
interface present in the ACPI tables (Rafael Wysocki).
- Update documentation related to system sleep and rename a number
of items in the code to make it cleare that they are related to
suspend-to-idle (Rafael Wysocki).
- Export a variable allowing device drivers to check the target
system sleep state from the core system suspend code (Florian
Fainelli).
- Clean up the cpuidle subsystem to handle the polling state on
x86 in a more straightforward way and to use %pOF instead of
full_name (Rafael Wysocki, Rob Herring).
- Update the devfreq framework to fix and clean up a few minor
issues (Chanwoo Choi, Rob Herring).
- Extend diagnostics in the generic power domains (genpd) framework
and clean it up slightly (Thara Gopinath, Rob Herring).
- Fix and clean up a couple of issues in the operating performance
points (OPP) framework (Viresh Kumar, Waldemar Rymarkiewicz).
- Add support for RV1108 to the rockchip-io Adaptive Voltage Scaling
(AVS) driver (David Wu).
- Fix the usage of notifiers in CPU power management on some
platforms (Alex Shi).
- Update the pm-graph system suspend/hibernation and boot profiling
utility (Todd Brandt).
- Make it possible to run the cpupower utility without CPU0 (Prarit
Bhargava).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJZrcDJAAoJEILEb/54YlRx9FUQAIUKvWBAARc61ZIZXjbqZF1v
aEMOBuksFns0CMekdptSic6n4wc81E/XYMS8yDhOOMpyDzfAZsTWjmu+gKwN7w3l
E/yf/NVlhob9JZ7MqGgqD4EUFfFIaKBXPlWFdDi2rdCUXE2L8xJ7rla8i7zyZlc5
pYHfAppBbF4qUcEY4OoOVOOGRZCfMdiLXj0iZOhMX8Y6yLBRk/AjnVADYsF33hoj
gBEfomU+H0K5V8nQEp0ZFKDArPwL+oElHQj6i+nxBpGfPM5evvLXhHOyR6AsldJ5
J4YI1kMuQNSCmvHMqOTxTYyJf8Jcf3Fj4wcjwaVMVGceY1lz6McAKknnFnCqCvz+
mskn84gFCBCM8EoJDqRf0b9MQHcuRyQKM+yw4tjnR9r8yd32erb85ZWFHcPWYhCT
fZatNOwFFv2MU+2vo5J3yeUNSWIKT+uBjy+tKPbrDkUwpKZVRj3Oj+hP3Mq9NE8U
YBqltsj7tmrdA634zI8C7jfS6wF221S0fId/iPszwmPJaVn/lq8Ror7pWL5YI8U7
SCJFjiqDiGmAcQEkuWwFAQnscZkyHpO+Y3A+jfXl/izoaZETaI5+ceIHBaocm3+5
XrOOpHS3ik8EHf9ji0KFCKZ/pYDwllday3cBQPWo3sMIzpQ2lrjbqdnE1cVnBrld
OtHZAeD/jLUXuY6XW2jN
=mAiV
-----END PGP SIGNATURE-----
Merge tag 'pm-4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management updates from Rafael Wysocki:
"This time (again) cpufreq gets the majority of changes which mostly
are driver updates (including a major consolidation of intel_pstate),
some schedutil governor modifications and core cleanups.
There also are some changes in the system suspend area, mostly related
to diagnostics and debug messages plus some renames of things related
to suspend-to-idle. One major change here is that suspend-to-idle is
now going to be preferred over S3 on systems where the ACPI tables
indicate to do so and provide requsite support (the Low Power Idle S0
_DSM in particular). The system sleep documentation and the tools
related to it are updated too.
The rest is a few cpuidle changes (nothing major), devfreq updates,
generic power domains (genpd) framework updates and a few assorted
modifications elsewhere.
Specifics:
- Drop the P-state selection algorithm based on a PID controller from
intel_pstate and make it use the same P-state selection method
(based on the CPU load) for all types of systems in the active mode
(Rafael Wysocki, Srinivas Pandruvada).
- Rework the cpufreq core and governors to make it possible to take
cross-CPU utilization updates into account and modify the schedutil
governor to actually do so (Viresh Kumar).
- Clean up the handling of transition latency information in the
cpufreq core and untangle it from the information on which drivers
cannot do dynamic frequency switching (Viresh Kumar).
- Add support for new SoCs (MT2701/MT7623 and MT7622) to the mediatek
cpufreq driver and update its DT bindings (Sean Wang).
- Modify the cpufreq dt-platdev driver to autimatically create
cpufreq devices for the new (v2) Operating Performance Points (OPP)
DT bindings and update its whitelist of supported systems (Viresh
Kumar, Shubhrajyoti Datta, Marc Gonzalez, Khiem Nguyen, Finley
Xiao).
- Add support for Ux500 to the cpufreq-dt driver and drop the
obsolete dbx500 cpufreq driver (Linus Walleij, Arnd Bergmann).
- Add new SoC (R8A7795) support to the cpufreq rcar driver (Khiem
Nguyen).
- Fix and clean up assorted issues in the cpufreq drivers and core
(Arvind Yadav, Christophe Jaillet, Colin Ian King, Gustavo Silva,
Julia Lawall, Leonard Crestez, Rob Herring, Sudeep Holla).
- Update the IO-wait boost handling in the schedutil governor to make
it less aggressive (Joel Fernandes).
- Rework system suspend diagnostics to make it print fewer messages
to the kernel log by default, add a sysfs knob to allow more
suspend-related messages to be printed and add Low Power S0 Idle
constraints checks to the ACPI suspend-to-idle code (Rafael
Wysocki, Srinivas Pandruvada).
- Prefer suspend-to-idle over S3 on ACPI-based systems with the
ACPI_FADT_LOW_POWER_S0 flag set and the Low Power Idle S0 _DSM
interface present in the ACPI tables (Rafael Wysocki).
- Update documentation related to system sleep and rename a number of
items in the code to make it cleare that they are related to
suspend-to-idle (Rafael Wysocki).
- Export a variable allowing device drivers to check the target
system sleep state from the core system suspend code (Florian
Fainelli).
- Clean up the cpuidle subsystem to handle the polling state on x86
in a more straightforward way and to use %pOF instead of full_name
(Rafael Wysocki, Rob Herring).
- Update the devfreq framework to fix and clean up a few minor issues
(Chanwoo Choi, Rob Herring).
- Extend diagnostics in the generic power domains (genpd) framework
and clean it up slightly (Thara Gopinath, Rob Herring).
- Fix and clean up a couple of issues in the operating performance
points (OPP) framework (Viresh Kumar, Waldemar Rymarkiewicz).
- Add support for RV1108 to the rockchip-io Adaptive Voltage Scaling
(AVS) driver (David Wu).
- Fix the usage of notifiers in CPU power management on some
platforms (Alex Shi).
- Update the pm-graph system suspend/hibernation and boot profiling
utility (Todd Brandt).
- Make it possible to run the cpupower utility without CPU0 (Prarit
Bhargava)"
* tag 'pm-4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (87 commits)
cpuidle: Make drivers initialize polling state
cpuidle: Move polling state initialization code to separate file
cpuidle: Eliminate the CPUIDLE_DRIVER_STATE_START symbol
cpufreq: imx6q: Fix imx6sx low frequency support
cpufreq: speedstep-lib: make several arrays static, makes code smaller
PM: docs: Delete the obsolete states.txt document
PM: docs: Describe high-level PM strategies and sleep states
PM / devfreq: Fix memory leak when fail to register device
PM / devfreq: Add dependency on PM_OPP
PM / devfreq: Move private devfreq_update_stats() into devfreq
PM / devfreq: Convert to using %pOF instead of full_name
PM / AVS: rockchip-io: add io selectors and supplies for RV1108
cpufreq: ti: Fix 'of_node_put' being called twice in error handling path
cpufreq: dt-platdev: Drop few entries from whitelist
cpufreq: dt-platdev: Automatically create cpufreq device with OPP v2
ARM: ux500: don't select CPUFREQ_DT
cpuidle: Convert to using %pOF instead of full_name
cpufreq: Convert to using %pOF instead of full_name
PM / Domains: Convert to using %pOF instead of full_name
cpufreq: Cap the default transition delay value to 10 ms
...
2017-09-05 19:19:08 +00:00
|
|
|
struct rq *rq = rq_of(cfs_rq);
|
|
|
|
|
2020-01-15 10:20:20 +00:00
|
|
|
if (&rq->cfs == cfs_rq) {
|
2017-05-24 05:29:52 +00:00
|
|
|
/*
|
|
|
|
* There are a few boundary cases this might miss but it should
|
|
|
|
* get called often enough that that should (hopefully) not be
|
2017-12-15 15:39:43 +00:00
|
|
|
* a real problem.
|
2017-05-24 05:29:52 +00:00
|
|
|
*
|
|
|
|
* It will not get called when we go idle, because the idle
|
|
|
|
* thread is a different class (!fair), nor will the utilization
|
|
|
|
* number include things like RT tasks.
|
|
|
|
*
|
|
|
|
* As is, the util number is not freq-invariant (we'd have to
|
|
|
|
* implement arch_scale_freq_capacity() for that).
|
|
|
|
*
|
|
|
|
* See cpu_util().
|
|
|
|
*/
|
2018-02-02 09:27:00 +00:00
|
|
|
cpufreq_update_util(rq, flags);
|
2017-05-24 05:29:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-26 05:05:39 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2012-10-04 11:18:30 +00:00
|
|
|
#ifdef CONFIG_FAIR_GROUP_SCHED
|
2016-07-13 08:56:25 +00:00
|
|
|
/**
|
|
|
|
* update_tg_load_avg - update the tg's load avg
|
|
|
|
* @cfs_rq: the cfs_rq whose avg changed
|
|
|
|
* @force: update regardless of how small the difference
|
|
|
|
*
|
|
|
|
* This function 'ensures': tg->load_avg := \Sum tg->cfs_rq[]->avg.load.
|
|
|
|
* However, because tg->load_avg is a global value there are performance
|
|
|
|
* considerations.
|
|
|
|
*
|
|
|
|
* In order to avoid having to look at the other cfs_rq's, we use a
|
|
|
|
* differential update where we store the last value we propagated. This in
|
|
|
|
* turn allows skipping updates if the differential is 'small'.
|
|
|
|
*
|
2017-06-23 16:55:30 +00:00
|
|
|
* Updating tg's load_avg is necessary before update_cfs_share().
|
2012-10-04 11:18:31 +00:00
|
|
|
*/
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
static inline void update_tg_load_avg(struct cfs_rq *cfs_rq, int force)
|
2012-10-04 11:18:31 +00:00
|
|
|
{
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
long delta = cfs_rq->avg.load_avg - cfs_rq->tg_load_avg_contrib;
|
2012-10-04 11:18:31 +00:00
|
|
|
|
2015-12-02 18:41:50 +00:00
|
|
|
/*
|
|
|
|
* No need to update load_avg for root_task_group as it is not used.
|
|
|
|
*/
|
|
|
|
if (cfs_rq->tg == &root_task_group)
|
|
|
|
return;
|
|
|
|
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
if (force || abs(delta) > cfs_rq->tg_load_avg_contrib / 64) {
|
|
|
|
atomic_long_add(delta, &cfs_rq->tg->load_avg);
|
|
|
|
cfs_rq->tg_load_avg_contrib = cfs_rq->avg.load_avg;
|
2012-10-04 11:18:31 +00:00
|
|
|
}
|
2012-10-04 11:18:31 +00:00
|
|
|
}
|
2014-02-26 11:19:33 +00:00
|
|
|
|
2015-10-23 16:16:19 +00:00
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Called within set_task_rq() right before setting a task's CPU. The
|
2015-10-23 16:16:19 +00:00
|
|
|
* caller only guarantees p->pi_lock is held; no other assumptions,
|
|
|
|
* including the state of rq->lock, should be made.
|
|
|
|
*/
|
|
|
|
void set_task_rq_fair(struct sched_entity *se,
|
|
|
|
struct cfs_rq *prev, struct cfs_rq *next)
|
|
|
|
{
|
2017-03-28 09:08:20 +00:00
|
|
|
u64 p_last_update_time;
|
|
|
|
u64 n_last_update_time;
|
|
|
|
|
2015-10-23 16:16:19 +00:00
|
|
|
if (!sched_feat(ATTACH_AGE_LOAD))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We are supposed to update the task to "current" time, then its up to
|
|
|
|
* date and ready to go to new CPU/cfs_rq. But we have difficulty in
|
|
|
|
* getting what current time is, so simply throw away the out-of-date
|
|
|
|
* time. This will result in the wakee task is less decayed, but giving
|
|
|
|
* the wakee more load sounds not bad.
|
|
|
|
*/
|
2017-03-28 09:08:20 +00:00
|
|
|
if (!(se->avg.last_update_time && prev))
|
|
|
|
return;
|
2015-10-23 16:16:19 +00:00
|
|
|
|
|
|
|
#ifndef CONFIG_64BIT
|
2017-03-28 09:08:20 +00:00
|
|
|
{
|
2015-10-23 16:16:19 +00:00
|
|
|
u64 p_last_update_time_copy;
|
|
|
|
u64 n_last_update_time_copy;
|
|
|
|
|
|
|
|
do {
|
|
|
|
p_last_update_time_copy = prev->load_last_update_time_copy;
|
|
|
|
n_last_update_time_copy = next->load_last_update_time_copy;
|
|
|
|
|
|
|
|
smp_rmb();
|
|
|
|
|
|
|
|
p_last_update_time = prev->avg.last_update_time;
|
|
|
|
n_last_update_time = next->avg.last_update_time;
|
|
|
|
|
|
|
|
} while (p_last_update_time != p_last_update_time_copy ||
|
|
|
|
n_last_update_time != n_last_update_time_copy);
|
2017-03-28 09:08:20 +00:00
|
|
|
}
|
2015-10-23 16:16:19 +00:00
|
|
|
#else
|
2017-03-28 09:08:20 +00:00
|
|
|
p_last_update_time = prev->avg.last_update_time;
|
|
|
|
n_last_update_time = next->avg.last_update_time;
|
2015-10-23 16:16:19 +00:00
|
|
|
#endif
|
sched/fair: Update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times:
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/seconds ops/seconds diff
cgroup
root 59652(+/- 0.18%) 59876(+/- 0.24%) +0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%) +0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%) +0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec) diff
cgroup
root 4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%) 138ms not reachable 276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%) 13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Morten.Rasmussen@arm.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: patrick.bellasi@arm.com
Cc: pjt@google.com
Cc: pkondeti@codeaurora.org
Cc: quentin.perret@arm.com
Cc: rjw@rjwysocki.net
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Link: https://lkml.kernel.org/r/1548257214-13745-3-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-01-23 15:26:53 +00:00
|
|
|
__update_load_avg_blocked_se(p_last_update_time, se);
|
2017-03-28 09:08:20 +00:00
|
|
|
se->avg.last_update_time = n_last_update_time;
|
2015-10-23 16:16:19 +00:00
|
|
|
}
|
2016-11-08 09:53:45 +00:00
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* When on migration a sched_entity joins/leaves the PELT hierarchy, we need to
|
|
|
|
* propagate its contribution. The key to this propagation is the invariant
|
|
|
|
* that for each group:
|
|
|
|
*
|
|
|
|
* ge->avg == grq->avg (1)
|
|
|
|
*
|
|
|
|
* _IFF_ we look at the pure running and runnable sums. Because they
|
|
|
|
* represent the very same entity, just at different points in the hierarchy.
|
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* Per the above update_tg_cfs_util() is trivial and simply copies the running
|
|
|
|
* sum over (but still wrong, because the group entity and group rq do not have
|
|
|
|
* their PELT windows aligned).
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
|
|
|
* However, update_tg_cfs_runnable() is more complex. So we have:
|
|
|
|
*
|
|
|
|
* ge->avg.load_avg = ge->load.weight * ge->avg.runnable_avg (2)
|
|
|
|
*
|
|
|
|
* And since, like util, the runnable part should be directly transferable,
|
|
|
|
* the following would _appear_ to be the straight forward approach:
|
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* grq->avg.load_avg = grq->load.weight * grq->avg.runnable_avg (3)
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
|
|
|
* And per (1) we have:
|
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* ge->avg.runnable_avg == grq->avg.runnable_avg
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
|
|
|
* Which gives:
|
|
|
|
*
|
|
|
|
* ge->load.weight * grq->avg.load_avg
|
|
|
|
* ge->avg.load_avg = ----------------------------------- (4)
|
|
|
|
* grq->load.weight
|
|
|
|
*
|
|
|
|
* Except that is wrong!
|
|
|
|
*
|
|
|
|
* Because while for entities historical weight is not important and we
|
|
|
|
* really only care about our future and therefore can consider a pure
|
|
|
|
* runnable sum, runqueues can NOT do this.
|
|
|
|
*
|
|
|
|
* We specifically want runqueues to have a load_avg that includes
|
|
|
|
* historical weights. Those represent the blocked load, the load we expect
|
|
|
|
* to (shortly) return to us. This only works by keeping the weights as
|
|
|
|
* integral part of the sum. We therefore cannot decompose as per (3).
|
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* Another reason this doesn't work is that runnable isn't a 0-sum entity.
|
|
|
|
* Imagine a rq with 2 tasks that each are runnable 2/3 of the time. Then the
|
|
|
|
* rq itself is runnable anywhere between 2/3 and 1 depending on how the
|
|
|
|
* runnable section of these tasks overlap (or not). If they were to perfectly
|
|
|
|
* align the rq as a whole would be runnable 2/3 of the time. If however we
|
|
|
|
* always have at least 1 runnable task, the rq as a whole is always runnable.
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* So we'll have to approximate.. :/
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* Given the constraint:
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* ge->avg.running_sum <= ge->avg.runnable_sum <= LOAD_AVG_MAX
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* We can construct a rule that adds runnable to a rq by assuming minimal
|
|
|
|
* overlap.
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* On removal, we'll assume each task is equally runnable; which yields:
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* grq->avg.runnable_sum = grq->avg.load_sum / grq->load.weight
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
2017-11-16 14:21:52 +00:00
|
|
|
* XXX: only do this for the part of runnable > running ?
|
2017-05-08 15:30:46 +00:00
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2016-11-08 09:53:45 +00:00
|
|
|
static inline void
|
2017-05-08 15:30:46 +00:00
|
|
|
update_tg_cfs_util(struct cfs_rq *cfs_rq, struct sched_entity *se, struct cfs_rq *gcfs_rq)
|
2016-11-08 09:53:45 +00:00
|
|
|
{
|
|
|
|
long delta = gcfs_rq->avg.util_avg - se->avg.util_avg;
|
|
|
|
|
|
|
|
/* Nothing to update */
|
|
|
|
if (!delta)
|
|
|
|
return;
|
|
|
|
|
2017-11-16 14:21:52 +00:00
|
|
|
/*
|
|
|
|
* The relation between sum and avg is:
|
|
|
|
*
|
|
|
|
* LOAD_AVG_MAX - 1024 + sa->period_contrib
|
|
|
|
*
|
|
|
|
* however, the PELT windows are not aligned between grq and gse.
|
|
|
|
*/
|
|
|
|
|
2016-11-08 09:53:45 +00:00
|
|
|
/* Set new sched_entity's utilization */
|
|
|
|
se->avg.util_avg = gcfs_rq->avg.util_avg;
|
|
|
|
se->avg.util_sum = se->avg.util_avg * LOAD_AVG_MAX;
|
|
|
|
|
|
|
|
/* Update parent cfs_rq utilization */
|
|
|
|
add_positive(&cfs_rq->avg.util_avg, delta);
|
|
|
|
cfs_rq->avg.util_sum = cfs_rq->avg.util_avg * LOAD_AVG_MAX;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
2017-05-08 15:30:46 +00:00
|
|
|
update_tg_cfs_runnable(struct cfs_rq *cfs_rq, struct sched_entity *se, struct cfs_rq *gcfs_rq)
|
2016-11-08 09:53:45 +00:00
|
|
|
{
|
2017-11-16 14:21:52 +00:00
|
|
|
long delta_avg, running_sum, runnable_sum = gcfs_rq->prop_runnable_sum;
|
|
|
|
unsigned long runnable_load_avg, load_avg;
|
|
|
|
u64 runnable_load_sum, load_sum = 0;
|
|
|
|
s64 delta_sum;
|
2016-11-08 09:53:45 +00:00
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
if (!runnable_sum)
|
|
|
|
return;
|
2016-11-08 09:53:45 +00:00
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
gcfs_rq->prop_runnable_sum = 0;
|
2016-11-08 09:53:45 +00:00
|
|
|
|
2017-11-16 14:21:52 +00:00
|
|
|
if (runnable_sum >= 0) {
|
|
|
|
/*
|
|
|
|
* Add runnable; clip at LOAD_AVG_MAX. Reflects that until
|
|
|
|
* the CPU is saturated running == runnable.
|
|
|
|
*/
|
|
|
|
runnable_sum += se->avg.load_sum;
|
|
|
|
runnable_sum = min(runnable_sum, (long)LOAD_AVG_MAX);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Estimate the new unweighted runnable_sum of the gcfs_rq by
|
|
|
|
* assuming all tasks are equally runnable.
|
|
|
|
*/
|
|
|
|
if (scale_load_down(gcfs_rq->load.weight)) {
|
|
|
|
load_sum = div_s64(gcfs_rq->avg.load_sum,
|
|
|
|
scale_load_down(gcfs_rq->load.weight));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* But make sure to not inflate se's runnable */
|
|
|
|
runnable_sum = min(se->avg.load_sum, load_sum);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* runnable_sum can't be lower than running_sum
|
sched/fair: Update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times:
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/seconds ops/seconds diff
cgroup
root 59652(+/- 0.18%) 59876(+/- 0.24%) +0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%) +0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%) +0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec) diff
cgroup
root 4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%) 138ms not reachable 276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%) 13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Morten.Rasmussen@arm.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: patrick.bellasi@arm.com
Cc: pjt@google.com
Cc: pkondeti@codeaurora.org
Cc: quentin.perret@arm.com
Cc: rjw@rjwysocki.net
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Link: https://lkml.kernel.org/r/1548257214-13745-3-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-01-23 15:26:53 +00:00
|
|
|
* Rescale running sum to be in the same range as runnable sum
|
|
|
|
* running_sum is in [0 : LOAD_AVG_MAX << SCHED_CAPACITY_SHIFT]
|
|
|
|
* runnable_sum is in [0 : LOAD_AVG_MAX]
|
2017-11-16 14:21:52 +00:00
|
|
|
*/
|
sched/fair: Update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times:
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/seconds ops/seconds diff
cgroup
root 59652(+/- 0.18%) 59876(+/- 0.24%) +0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%) +0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%) +0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec) diff
cgroup
root 4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%) 138ms not reachable 276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%) 13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Morten.Rasmussen@arm.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: patrick.bellasi@arm.com
Cc: pjt@google.com
Cc: pkondeti@codeaurora.org
Cc: quentin.perret@arm.com
Cc: rjw@rjwysocki.net
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Link: https://lkml.kernel.org/r/1548257214-13745-3-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-01-23 15:26:53 +00:00
|
|
|
running_sum = se->avg.util_sum >> SCHED_CAPACITY_SHIFT;
|
2017-11-16 14:21:52 +00:00
|
|
|
runnable_sum = max(runnable_sum, running_sum);
|
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
load_sum = (s64)se_weight(se) * runnable_sum;
|
|
|
|
load_avg = div_s64(load_sum, LOAD_AVG_MAX);
|
2016-11-08 09:53:45 +00:00
|
|
|
|
2017-11-16 14:21:52 +00:00
|
|
|
delta_sum = load_sum - (s64)se_weight(se) * se->avg.load_sum;
|
|
|
|
delta_avg = load_avg - se->avg.load_avg;
|
2016-11-08 09:53:45 +00:00
|
|
|
|
2017-11-16 14:21:52 +00:00
|
|
|
se->avg.load_sum = runnable_sum;
|
|
|
|
se->avg.load_avg = load_avg;
|
|
|
|
add_positive(&cfs_rq->avg.load_avg, delta_avg);
|
|
|
|
add_positive(&cfs_rq->avg.load_sum, delta_sum);
|
2016-11-08 09:53:45 +00:00
|
|
|
|
2017-05-06 13:59:54 +00:00
|
|
|
runnable_load_sum = (s64)se_runnable(se) * runnable_sum;
|
|
|
|
runnable_load_avg = div_s64(runnable_load_sum, LOAD_AVG_MAX);
|
|
|
|
|
2016-11-08 09:53:45 +00:00
|
|
|
if (se->on_rq) {
|
2020-01-03 11:44:00 +00:00
|
|
|
delta_sum = runnable_load_sum -
|
|
|
|
se_weight(se) * se->avg.runnable_load_sum;
|
|
|
|
delta_avg = runnable_load_avg - se->avg.runnable_load_avg;
|
2017-11-16 14:21:52 +00:00
|
|
|
add_positive(&cfs_rq->avg.runnable_load_avg, delta_avg);
|
|
|
|
add_positive(&cfs_rq->avg.runnable_load_sum, delta_sum);
|
2016-11-08 09:53:45 +00:00
|
|
|
}
|
2020-01-03 11:44:00 +00:00
|
|
|
|
|
|
|
se->avg.runnable_load_sum = runnable_sum;
|
|
|
|
se->avg.runnable_load_avg = runnable_load_avg;
|
2016-11-08 09:53:45 +00:00
|
|
|
}
|
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
static inline void add_tg_cfs_propagate(struct cfs_rq *cfs_rq, long runnable_sum)
|
2016-11-08 09:53:45 +00:00
|
|
|
{
|
2017-05-08 15:30:46 +00:00
|
|
|
cfs_rq->propagate = 1;
|
|
|
|
cfs_rq->prop_runnable_sum += runnable_sum;
|
2016-11-08 09:53:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Update task and its cfs_rq load average */
|
|
|
|
static inline int propagate_entity_load_avg(struct sched_entity *se)
|
|
|
|
{
|
2017-05-08 15:30:46 +00:00
|
|
|
struct cfs_rq *cfs_rq, *gcfs_rq;
|
2016-11-08 09:53:45 +00:00
|
|
|
|
|
|
|
if (entity_is_task(se))
|
|
|
|
return 0;
|
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
gcfs_rq = group_cfs_rq(se);
|
|
|
|
if (!gcfs_rq->propagate)
|
2016-11-08 09:53:45 +00:00
|
|
|
return 0;
|
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
gcfs_rq->propagate = 0;
|
|
|
|
|
2016-11-08 09:53:45 +00:00
|
|
|
cfs_rq = cfs_rq_of(se);
|
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
add_tg_cfs_propagate(cfs_rq, gcfs_rq->prop_runnable_sum);
|
2016-11-08 09:53:45 +00:00
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
update_tg_cfs_util(cfs_rq, se, gcfs_rq);
|
|
|
|
update_tg_cfs_runnable(cfs_rq, se, gcfs_rq);
|
2016-11-08 09:53:45 +00:00
|
|
|
|
2019-06-04 11:14:56 +00:00
|
|
|
trace_pelt_cfs_tp(cfs_rq);
|
2019-06-04 11:14:57 +00:00
|
|
|
trace_pelt_se_tp(se);
|
2019-06-04 11:14:56 +00:00
|
|
|
|
2016-11-08 09:53:45 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-03-17 13:47:22 +00:00
|
|
|
/*
|
|
|
|
* Check if we need to update the load and the utilization of a blocked
|
|
|
|
* group_entity:
|
|
|
|
*/
|
|
|
|
static inline bool skip_blocked_update(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
struct cfs_rq *gcfs_rq = group_cfs_rq(se);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If sched_entity still have not zero load or utilization, we have to
|
|
|
|
* decay it:
|
|
|
|
*/
|
|
|
|
if (se->avg.load_avg || se->avg.util_avg)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there is a pending propagation, we have to update the load and
|
|
|
|
* the utilization of the sched_entity:
|
|
|
|
*/
|
2017-05-08 15:30:46 +00:00
|
|
|
if (gcfs_rq->propagate)
|
2017-03-17 13:47:22 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Otherwise, the load and the utilization of the sched_entity is
|
|
|
|
* already zero and there is no pending propagation, so it will be a
|
|
|
|
* waste of time to try to decay it:
|
|
|
|
*/
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-02-11 15:11:48 +00:00
|
|
|
#else /* CONFIG_FAIR_GROUP_SCHED */
|
2016-11-08 09:53:45 +00:00
|
|
|
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
static inline void update_tg_load_avg(struct cfs_rq *cfs_rq, int force) {}
|
2016-11-08 09:53:45 +00:00
|
|
|
|
|
|
|
static inline int propagate_entity_load_avg(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
static inline void add_tg_cfs_propagate(struct cfs_rq *cfs_rq, long runnable_sum) {}
|
2016-11-08 09:53:45 +00:00
|
|
|
|
2014-02-11 15:11:48 +00:00
|
|
|
#endif /* CONFIG_FAIR_GROUP_SCHED */
|
2012-10-04 11:18:30 +00:00
|
|
|
|
2016-06-21 12:27:50 +00:00
|
|
|
/**
|
|
|
|
* update_cfs_rq_load_avg - update the cfs_rq's load/util averages
|
sched/fair: Update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times:
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/seconds ops/seconds diff
cgroup
root 59652(+/- 0.18%) 59876(+/- 0.24%) +0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%) +0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%) +0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec) diff
cgroup
root 4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%) 138ms not reachable 276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%) 13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Morten.Rasmussen@arm.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: patrick.bellasi@arm.com
Cc: pjt@google.com
Cc: pkondeti@codeaurora.org
Cc: quentin.perret@arm.com
Cc: rjw@rjwysocki.net
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Link: https://lkml.kernel.org/r/1548257214-13745-3-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-01-23 15:26:53 +00:00
|
|
|
* @now: current time, as per cfs_rq_clock_pelt()
|
2016-06-21 12:27:50 +00:00
|
|
|
* @cfs_rq: cfs_rq to update
|
|
|
|
*
|
|
|
|
* The cfs_rq avg is the direct sum of all its entities (blocked and runnable)
|
|
|
|
* avg. The immediate corollary is that all (fair) tasks must be attached, see
|
|
|
|
* post_init_entity_util_avg().
|
|
|
|
*
|
|
|
|
* cfs_rq->avg is used for task_h_load() and update_cfs_share() for example.
|
|
|
|
*
|
2016-07-13 08:56:25 +00:00
|
|
|
* Returns true if the load decayed or we removed load.
|
|
|
|
*
|
|
|
|
* Since both these conditions indicate a changed cfs_rq->avg.load we should
|
|
|
|
* call update_tg_load_avg() when this function returns true.
|
2016-06-21 12:27:50 +00:00
|
|
|
*/
|
2016-03-24 22:26:07 +00:00
|
|
|
static inline int
|
2017-05-24 05:29:56 +00:00
|
|
|
update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
|
2012-10-04 11:18:30 +00:00
|
|
|
{
|
2017-05-08 15:30:46 +00:00
|
|
|
unsigned long removed_load = 0, removed_util = 0, removed_runnable_sum = 0;
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
struct sched_avg *sa = &cfs_rq->avg;
|
2017-05-08 14:51:41 +00:00
|
|
|
int decayed = 0;
|
2012-10-04 11:18:30 +00:00
|
|
|
|
2017-05-08 14:51:41 +00:00
|
|
|
if (cfs_rq->removed.nr) {
|
|
|
|
unsigned long r;
|
2017-05-12 12:18:10 +00:00
|
|
|
u32 divider = LOAD_AVG_MAX - 1024 + sa->period_contrib;
|
2017-05-08 14:51:41 +00:00
|
|
|
|
|
|
|
raw_spin_lock(&cfs_rq->removed.lock);
|
|
|
|
swap(cfs_rq->removed.util_avg, removed_util);
|
|
|
|
swap(cfs_rq->removed.load_avg, removed_load);
|
2017-05-08 15:30:46 +00:00
|
|
|
swap(cfs_rq->removed.runnable_sum, removed_runnable_sum);
|
2017-05-08 14:51:41 +00:00
|
|
|
cfs_rq->removed.nr = 0;
|
|
|
|
raw_spin_unlock(&cfs_rq->removed.lock);
|
|
|
|
|
|
|
|
r = removed_load;
|
sched/fair: Fix cfs_rq avg tracking underflow
As per commit:
b7fa30c9cc48 ("sched/fair: Fix post_init_entity_util_avg() serialization")
> the code generated from update_cfs_rq_load_avg():
>
> if (atomic_long_read(&cfs_rq->removed_load_avg)) {
> s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
> sa->load_avg = max_t(long, sa->load_avg - r, 0);
> sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
> removed_load = 1;
> }
>
> turns into:
>
> ffffffff81087064: 49 8b 85 98 00 00 00 mov 0x98(%r13),%rax
> ffffffff8108706b: 48 85 c0 test %rax,%rax
> ffffffff8108706e: 74 40 je ffffffff810870b0 <update_blocked_averages+0xc0>
> ffffffff81087070: 4c 89 f8 mov %r15,%rax
> ffffffff81087073: 49 87 85 98 00 00 00 xchg %rax,0x98(%r13)
> ffffffff8108707a: 49 29 45 70 sub %rax,0x70(%r13)
> ffffffff8108707e: 4c 89 f9 mov %r15,%rcx
> ffffffff81087081: bb 01 00 00 00 mov $0x1,%ebx
> ffffffff81087086: 49 83 7d 70 00 cmpq $0x0,0x70(%r13)
> ffffffff8108708b: 49 0f 49 4d 70 cmovns 0x70(%r13),%rcx
>
> Which you'll note ends up with sa->load_avg -= r in memory at
> ffffffff8108707a.
So I _should_ have looked at other unserialized users of ->load_avg,
but alas. Luckily nikbor reported a similar /0 from task_h_load() which
instantly triggered recollection of this here problem.
Aside from the intermediate value hitting memory and causing problems,
there's another problem: the underflow detection relies on the signed
bit. This reduces the effective width of the variables, IOW its
effectively the same as having these variables be of signed type.
This patch changes to a different means of unsigned underflow
detection to not rely on the signed bit. This allows the variables to
use the 'full' unsigned range. And it does so with explicit LOAD -
STORE to ensure any intermediate value will never be visible in
memory, allowing these unserialized loads.
Note: GCC generates crap code for this, might warrant a look later.
Note2: I say 'full' above, if we end up at U*_MAX we'll still explode;
maybe we should do clamping on add too.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yuyang Du <yuyang.du@intel.com>
Cc: bsegall@google.com
Cc: kernel@kyup.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: steve.muckle@linaro.org
Fixes: 9d89c257dfb9 ("sched/fair: Rewrite runnable load and utilization average tracking")
Link: http://lkml.kernel.org/r/20160617091948.GJ30927@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-16 08:50:40 +00:00
|
|
|
sub_positive(&sa->load_avg, r);
|
2017-05-12 12:18:10 +00:00
|
|
|
sub_positive(&sa->load_sum, r * divider);
|
2012-10-04 11:18:30 +00:00
|
|
|
|
2017-05-08 14:51:41 +00:00
|
|
|
r = removed_util;
|
sched/fair: Fix cfs_rq avg tracking underflow
As per commit:
b7fa30c9cc48 ("sched/fair: Fix post_init_entity_util_avg() serialization")
> the code generated from update_cfs_rq_load_avg():
>
> if (atomic_long_read(&cfs_rq->removed_load_avg)) {
> s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
> sa->load_avg = max_t(long, sa->load_avg - r, 0);
> sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
> removed_load = 1;
> }
>
> turns into:
>
> ffffffff81087064: 49 8b 85 98 00 00 00 mov 0x98(%r13),%rax
> ffffffff8108706b: 48 85 c0 test %rax,%rax
> ffffffff8108706e: 74 40 je ffffffff810870b0 <update_blocked_averages+0xc0>
> ffffffff81087070: 4c 89 f8 mov %r15,%rax
> ffffffff81087073: 49 87 85 98 00 00 00 xchg %rax,0x98(%r13)
> ffffffff8108707a: 49 29 45 70 sub %rax,0x70(%r13)
> ffffffff8108707e: 4c 89 f9 mov %r15,%rcx
> ffffffff81087081: bb 01 00 00 00 mov $0x1,%ebx
> ffffffff81087086: 49 83 7d 70 00 cmpq $0x0,0x70(%r13)
> ffffffff8108708b: 49 0f 49 4d 70 cmovns 0x70(%r13),%rcx
>
> Which you'll note ends up with sa->load_avg -= r in memory at
> ffffffff8108707a.
So I _should_ have looked at other unserialized users of ->load_avg,
but alas. Luckily nikbor reported a similar /0 from task_h_load() which
instantly triggered recollection of this here problem.
Aside from the intermediate value hitting memory and causing problems,
there's another problem: the underflow detection relies on the signed
bit. This reduces the effective width of the variables, IOW its
effectively the same as having these variables be of signed type.
This patch changes to a different means of unsigned underflow
detection to not rely on the signed bit. This allows the variables to
use the 'full' unsigned range. And it does so with explicit LOAD -
STORE to ensure any intermediate value will never be visible in
memory, allowing these unserialized loads.
Note: GCC generates crap code for this, might warrant a look later.
Note2: I say 'full' above, if we end up at U*_MAX we'll still explode;
maybe we should do clamping on add too.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yuyang Du <yuyang.du@intel.com>
Cc: bsegall@google.com
Cc: kernel@kyup.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: steve.muckle@linaro.org
Fixes: 9d89c257dfb9 ("sched/fair: Rewrite runnable load and utilization average tracking")
Link: http://lkml.kernel.org/r/20160617091948.GJ30927@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-16 08:50:40 +00:00
|
|
|
sub_positive(&sa->util_avg, r);
|
2017-05-12 12:18:10 +00:00
|
|
|
sub_positive(&sa->util_sum, r * divider);
|
2017-05-08 14:51:41 +00:00
|
|
|
|
2017-05-08 15:30:46 +00:00
|
|
|
add_tg_cfs_propagate(cfs_rq, -(long)removed_runnable_sum);
|
2017-05-08 14:51:41 +00:00
|
|
|
|
|
|
|
decayed = 1;
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
}
|
2015-02-27 15:54:04 +00:00
|
|
|
|
sched/fair: Update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times:
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/seconds ops/seconds diff
cgroup
root 59652(+/- 0.18%) 59876(+/- 0.24%) +0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%) +0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%) +0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec) diff
cgroup
root 4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%) 138ms not reachable 276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%) 13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Morten.Rasmussen@arm.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: patrick.bellasi@arm.com
Cc: pjt@google.com
Cc: pkondeti@codeaurora.org
Cc: quentin.perret@arm.com
Cc: rjw@rjwysocki.net
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Link: https://lkml.kernel.org/r/1548257214-13745-3-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-01-23 15:26:53 +00:00
|
|
|
decayed |= __update_load_avg_cfs_rq(now, cfs_rq);
|
2015-02-27 15:54:04 +00:00
|
|
|
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
#ifndef CONFIG_64BIT
|
|
|
|
smp_wmb();
|
|
|
|
cfs_rq->load_last_update_time_copy = sa->last_update_time;
|
|
|
|
#endif
|
2015-02-27 15:54:04 +00:00
|
|
|
|
2017-05-08 14:51:41 +00:00
|
|
|
return decayed;
|
2016-03-22 00:21:07 +00:00
|
|
|
}
|
|
|
|
|
2016-06-21 12:27:50 +00:00
|
|
|
/**
|
|
|
|
* attach_entity_load_avg - attach this entity to its cfs_rq load avg
|
|
|
|
* @cfs_rq: cfs_rq to attach to
|
|
|
|
* @se: sched_entity to attach
|
2018-09-03 19:53:17 +00:00
|
|
|
* @flags: migration hints
|
2016-06-21 12:27:50 +00:00
|
|
|
*
|
|
|
|
* Must call update_cfs_rq_load_avg() before this, since we rely on
|
|
|
|
* cfs_rq->avg.last_update_time being current.
|
|
|
|
*/
|
2020-01-15 10:20:20 +00:00
|
|
|
static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
2015-08-20 11:21:56 +00:00
|
|
|
{
|
sched/fair: Align PELT windows between cfs_rq and its se
The PELT _sum values are a saw-tooth function, dropping on the decay
edge and then growing back up again during the window.
When these window-edges are not aligned between cfs_rq and se, we can
have the situation where, for example, on dequeue, the se decays
first.
Its _sum values will be small(er), while the cfs_rq _sum values will
still be on their way up. Because of this, the subtraction:
cfs_rq->avg._sum -= se->avg._sum will result in a positive value. This
will then, once the cfs_rq reaches an edge, translate into its _avg
value jumping up.
This is especially visible with the runnable_load bits, since they get
added/subtracted a lot.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-12 12:16:30 +00:00
|
|
|
u32 divider = LOAD_AVG_MAX - 1024 + cfs_rq->avg.period_contrib;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When we attach the @se to the @cfs_rq, we must align the decay
|
|
|
|
* window because without that, really weird and wonderful things can
|
|
|
|
* happen.
|
|
|
|
*
|
|
|
|
* XXX illustrate
|
|
|
|
*/
|
2015-08-20 11:21:56 +00:00
|
|
|
se->avg.last_update_time = cfs_rq->avg.last_update_time;
|
sched/fair: Align PELT windows between cfs_rq and its se
The PELT _sum values are a saw-tooth function, dropping on the decay
edge and then growing back up again during the window.
When these window-edges are not aligned between cfs_rq and se, we can
have the situation where, for example, on dequeue, the se decays
first.
Its _sum values will be small(er), while the cfs_rq _sum values will
still be on their way up. Because of this, the subtraction:
cfs_rq->avg._sum -= se->avg._sum will result in a positive value. This
will then, once the cfs_rq reaches an edge, translate into its _avg
value jumping up.
This is especially visible with the runnable_load bits, since they get
added/subtracted a lot.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-12 12:16:30 +00:00
|
|
|
se->avg.period_contrib = cfs_rq->avg.period_contrib;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Hell(o) Nasty stuff.. we need to recompute _sum based on the new
|
|
|
|
* period_contrib. This isn't strictly correct, but since we're
|
|
|
|
* entirely outside of the PELT hierarchy, nobody cares if we truncate
|
|
|
|
* _sum a little.
|
|
|
|
*/
|
|
|
|
se->avg.util_sum = se->avg.util_avg * divider;
|
|
|
|
|
|
|
|
se->avg.load_sum = divider;
|
|
|
|
if (se_weight(se)) {
|
|
|
|
se->avg.load_sum =
|
|
|
|
div_u64(se->avg.load_avg * se->avg.load_sum, se_weight(se));
|
|
|
|
}
|
|
|
|
|
|
|
|
se->avg.runnable_load_sum = se->avg.load_sum;
|
|
|
|
|
2017-08-24 15:45:35 +00:00
|
|
|
enqueue_load_avg(cfs_rq, se);
|
2015-08-20 11:21:56 +00:00
|
|
|
cfs_rq->avg.util_avg += se->avg.util_avg;
|
|
|
|
cfs_rq->avg.util_sum += se->avg.util_sum;
|
2017-05-08 15:30:46 +00:00
|
|
|
|
|
|
|
add_tg_cfs_propagate(cfs_rq, se->avg.load_sum);
|
2016-03-24 22:26:07 +00:00
|
|
|
|
2020-01-15 10:20:20 +00:00
|
|
|
cfs_rq_util_change(cfs_rq, 0);
|
2019-06-04 11:14:56 +00:00
|
|
|
|
|
|
|
trace_pelt_cfs_tp(cfs_rq);
|
2015-08-20 11:21:56 +00:00
|
|
|
}
|
|
|
|
|
2016-06-21 12:27:50 +00:00
|
|
|
/**
|
|
|
|
* detach_entity_load_avg - detach this entity from its cfs_rq load avg
|
|
|
|
* @cfs_rq: cfs_rq to detach from
|
|
|
|
* @se: sched_entity to detach
|
|
|
|
*
|
|
|
|
* Must call update_cfs_rq_load_avg() before this, since we rely on
|
|
|
|
* cfs_rq->avg.last_update_time being current.
|
|
|
|
*/
|
2015-08-20 11:21:56 +00:00
|
|
|
static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
2017-08-24 15:45:35 +00:00
|
|
|
dequeue_load_avg(cfs_rq, se);
|
sched/fair: Fix cfs_rq avg tracking underflow
As per commit:
b7fa30c9cc48 ("sched/fair: Fix post_init_entity_util_avg() serialization")
> the code generated from update_cfs_rq_load_avg():
>
> if (atomic_long_read(&cfs_rq->removed_load_avg)) {
> s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
> sa->load_avg = max_t(long, sa->load_avg - r, 0);
> sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
> removed_load = 1;
> }
>
> turns into:
>
> ffffffff81087064: 49 8b 85 98 00 00 00 mov 0x98(%r13),%rax
> ffffffff8108706b: 48 85 c0 test %rax,%rax
> ffffffff8108706e: 74 40 je ffffffff810870b0 <update_blocked_averages+0xc0>
> ffffffff81087070: 4c 89 f8 mov %r15,%rax
> ffffffff81087073: 49 87 85 98 00 00 00 xchg %rax,0x98(%r13)
> ffffffff8108707a: 49 29 45 70 sub %rax,0x70(%r13)
> ffffffff8108707e: 4c 89 f9 mov %r15,%rcx
> ffffffff81087081: bb 01 00 00 00 mov $0x1,%ebx
> ffffffff81087086: 49 83 7d 70 00 cmpq $0x0,0x70(%r13)
> ffffffff8108708b: 49 0f 49 4d 70 cmovns 0x70(%r13),%rcx
>
> Which you'll note ends up with sa->load_avg -= r in memory at
> ffffffff8108707a.
So I _should_ have looked at other unserialized users of ->load_avg,
but alas. Luckily nikbor reported a similar /0 from task_h_load() which
instantly triggered recollection of this here problem.
Aside from the intermediate value hitting memory and causing problems,
there's another problem: the underflow detection relies on the signed
bit. This reduces the effective width of the variables, IOW its
effectively the same as having these variables be of signed type.
This patch changes to a different means of unsigned underflow
detection to not rely on the signed bit. This allows the variables to
use the 'full' unsigned range. And it does so with explicit LOAD -
STORE to ensure any intermediate value will never be visible in
memory, allowing these unserialized loads.
Note: GCC generates crap code for this, might warrant a look later.
Note2: I say 'full' above, if we end up at U*_MAX we'll still explode;
maybe we should do clamping on add too.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yuyang Du <yuyang.du@intel.com>
Cc: bsegall@google.com
Cc: kernel@kyup.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: steve.muckle@linaro.org
Fixes: 9d89c257dfb9 ("sched/fair: Rewrite runnable load and utilization average tracking")
Link: http://lkml.kernel.org/r/20160617091948.GJ30927@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-16 08:50:40 +00:00
|
|
|
sub_positive(&cfs_rq->avg.util_avg, se->avg.util_avg);
|
|
|
|
sub_positive(&cfs_rq->avg.util_sum, se->avg.util_sum);
|
2017-05-08 15:30:46 +00:00
|
|
|
|
|
|
|
add_tg_cfs_propagate(cfs_rq, -se->avg.load_sum);
|
2016-03-24 22:26:07 +00:00
|
|
|
|
2018-02-02 09:27:00 +00:00
|
|
|
cfs_rq_util_change(cfs_rq, 0);
|
2019-06-04 11:14:56 +00:00
|
|
|
|
|
|
|
trace_pelt_cfs_tp(cfs_rq);
|
2015-08-20 11:21:56 +00:00
|
|
|
}
|
|
|
|
|
2017-05-06 15:37:03 +00:00
|
|
|
/*
|
|
|
|
* Optional action to be done while updating the load average
|
|
|
|
*/
|
|
|
|
#define UPDATE_TG 0x1
|
|
|
|
#define SKIP_AGE_LOAD 0x2
|
|
|
|
#define DO_ATTACH 0x4
|
|
|
|
|
|
|
|
/* Update task and its cfs_rq load average */
|
|
|
|
static inline void update_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags)
|
|
|
|
{
|
sched/fair: Update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times:
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/seconds ops/seconds diff
cgroup
root 59652(+/- 0.18%) 59876(+/- 0.24%) +0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%) +0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%) +0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec) diff
cgroup
root 4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%) 138ms not reachable 276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%) 13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Morten.Rasmussen@arm.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: patrick.bellasi@arm.com
Cc: pjt@google.com
Cc: pkondeti@codeaurora.org
Cc: quentin.perret@arm.com
Cc: rjw@rjwysocki.net
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Link: https://lkml.kernel.org/r/1548257214-13745-3-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-01-23 15:26:53 +00:00
|
|
|
u64 now = cfs_rq_clock_pelt(cfs_rq);
|
2017-05-06 15:37:03 +00:00
|
|
|
int decayed;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Track task load average for carrying it to new CPU after migrated, and
|
|
|
|
* track group sched_entity load average for task_h_load calc in migration
|
|
|
|
*/
|
|
|
|
if (se->avg.last_update_time && !(flags & SKIP_AGE_LOAD))
|
sched/fair: Update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times:
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/seconds ops/seconds diff
cgroup
root 59652(+/- 0.18%) 59876(+/- 0.24%) +0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%) +0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%) +0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec) diff
cgroup
root 4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%) 138ms not reachable 276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%) 13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Morten.Rasmussen@arm.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: patrick.bellasi@arm.com
Cc: pjt@google.com
Cc: pkondeti@codeaurora.org
Cc: quentin.perret@arm.com
Cc: rjw@rjwysocki.net
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Link: https://lkml.kernel.org/r/1548257214-13745-3-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-01-23 15:26:53 +00:00
|
|
|
__update_load_avg_se(now, cfs_rq, se);
|
2017-05-06 15:37:03 +00:00
|
|
|
|
|
|
|
decayed = update_cfs_rq_load_avg(now, cfs_rq);
|
|
|
|
decayed |= propagate_entity_load_avg(se);
|
|
|
|
|
|
|
|
if (!se->avg.last_update_time && (flags & DO_ATTACH)) {
|
|
|
|
|
2018-02-02 09:27:00 +00:00
|
|
|
/*
|
|
|
|
* DO_ATTACH means we're here from enqueue_entity().
|
|
|
|
* !last_update_time means we've passed through
|
|
|
|
* migrate_task_rq_fair() indicating we migrated.
|
|
|
|
*
|
|
|
|
* IOW we're enqueueing a task on a new CPU.
|
|
|
|
*/
|
2020-01-15 10:20:20 +00:00
|
|
|
attach_entity_load_avg(cfs_rq, se);
|
2017-05-06 15:37:03 +00:00
|
|
|
update_tg_load_avg(cfs_rq, 0);
|
|
|
|
|
2019-11-18 13:21:19 +00:00
|
|
|
} else if (decayed) {
|
|
|
|
cfs_rq_util_change(cfs_rq, 0);
|
|
|
|
|
|
|
|
if (flags & UPDATE_TG)
|
|
|
|
update_tg_load_avg(cfs_rq, 0);
|
|
|
|
}
|
2017-05-06 15:37:03 +00:00
|
|
|
}
|
|
|
|
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
#ifndef CONFIG_64BIT
|
2015-12-16 23:34:27 +00:00
|
|
|
static inline u64 cfs_rq_last_update_time(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
u64 last_update_time_copy;
|
2015-12-16 23:34:27 +00:00
|
|
|
u64 last_update_time;
|
2012-10-04 11:18:30 +00:00
|
|
|
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
do {
|
|
|
|
last_update_time_copy = cfs_rq->load_last_update_time_copy;
|
|
|
|
smp_rmb();
|
|
|
|
last_update_time = cfs_rq->avg.last_update_time;
|
|
|
|
} while (last_update_time != last_update_time_copy);
|
2015-12-16 23:34:27 +00:00
|
|
|
|
|
|
|
return last_update_time;
|
|
|
|
}
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
#else
|
2015-12-16 23:34:27 +00:00
|
|
|
static inline u64 cfs_rq_last_update_time(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
return cfs_rq->avg.last_update_time;
|
|
|
|
}
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
#endif
|
|
|
|
|
2016-10-14 13:41:07 +00:00
|
|
|
/*
|
|
|
|
* Synchronize entity load avg of dequeued entity without locking
|
|
|
|
* the previous rq.
|
|
|
|
*/
|
2019-03-20 13:38:39 +00:00
|
|
|
static void sync_entity_load_avg(struct sched_entity *se)
|
2016-10-14 13:41:07 +00:00
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
|
|
|
u64 last_update_time;
|
|
|
|
|
|
|
|
last_update_time = cfs_rq_last_update_time(cfs_rq);
|
sched/fair: Update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times:
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/seconds ops/seconds diff
cgroup
root 59652(+/- 0.18%) 59876(+/- 0.24%) +0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%) +0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%) +0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec) diff
cgroup
root 4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%) 138ms not reachable 276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%) 13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Morten.Rasmussen@arm.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: patrick.bellasi@arm.com
Cc: pjt@google.com
Cc: pkondeti@codeaurora.org
Cc: quentin.perret@arm.com
Cc: rjw@rjwysocki.net
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Link: https://lkml.kernel.org/r/1548257214-13745-3-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-01-23 15:26:53 +00:00
|
|
|
__update_load_avg_blocked_se(last_update_time, se);
|
2016-10-14 13:41:07 +00:00
|
|
|
}
|
|
|
|
|
2015-12-16 23:34:27 +00:00
|
|
|
/*
|
|
|
|
* Task first catches up with cfs_rq, and then subtract
|
|
|
|
* itself from the cfs_rq (task must be off the queue now).
|
|
|
|
*/
|
2019-03-20 13:38:39 +00:00
|
|
|
static void remove_entity_load_avg(struct sched_entity *se)
|
2015-12-16 23:34:27 +00:00
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
2017-05-08 14:51:41 +00:00
|
|
|
unsigned long flags;
|
2015-12-16 23:34:27 +00:00
|
|
|
|
|
|
|
/*
|
2016-06-16 11:29:28 +00:00
|
|
|
* tasks cannot exit without having gone through wake_up_new_task() ->
|
|
|
|
* post_init_entity_util_avg() which will have added things to the
|
|
|
|
* cfs_rq, so we can remove unconditionally.
|
2015-12-16 23:34:27 +00:00
|
|
|
*/
|
|
|
|
|
2016-10-14 13:41:07 +00:00
|
|
|
sync_entity_load_avg(se);
|
2017-05-08 14:51:41 +00:00
|
|
|
|
|
|
|
raw_spin_lock_irqsave(&cfs_rq->removed.lock, flags);
|
|
|
|
++cfs_rq->removed.nr;
|
|
|
|
cfs_rq->removed.util_avg += se->avg.util_avg;
|
|
|
|
cfs_rq->removed.load_avg += se->avg.load_avg;
|
2017-05-08 15:30:46 +00:00
|
|
|
cfs_rq->removed.runnable_sum += se->avg.load_sum; /* == runnable_sum */
|
2017-05-08 14:51:41 +00:00
|
|
|
raw_spin_unlock_irqrestore(&cfs_rq->removed.lock, flags);
|
2012-10-04 11:18:30 +00:00
|
|
|
}
|
sched: Fix wrong rq's runnable_avg update with rt tasks
The current update of the rq's load can be erroneous when RT
tasks are involved.
The update of the load of a rq that becomes idle, is done only
if the avg_idle is less than sysctl_sched_migration_cost. If RT
tasks and short idle duration alternate, the runnable_avg will
not be updated correctly and the time will be accounted as idle
time when a CFS task wakes up.
A new idle_enter function is called when the next task is the
idle function so the elapsed time will be accounted as run time
in the load of the rq, whatever the average idle time is. The
function update_rq_runnable_avg is removed from idle_balance.
When a RT task is scheduled on an idle CPU, the update of the
rq's load is not done when the rq exit idle state because CFS's
functions are not called. Then, the idle_balance, which is
called just before entering the idle function, updates the rq's
load and makes the assumption that the elapsed time since the
last update, was only running time.
As a consequence, the rq's load of a CPU that only runs a
periodic RT task, is close to LOAD_AVG_MAX whatever the running
duration of the RT task is.
A new idle_exit function is called when the prev task is the
idle function so the elapsed time will be accounted as idle time
in the rq's load.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: linaro-kernel@lists.linaro.org
Cc: peterz@infradead.org
Cc: pjt@google.com
Cc: fweisbec@gmail.com
Cc: efault@gmx.de
Link: http://lkml.kernel.org/r/1366302867-5055-1-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-04-18 16:34:26 +00:00
|
|
|
|
2015-07-15 00:04:42 +00:00
|
|
|
static inline unsigned long cfs_rq_runnable_load_avg(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
2017-05-06 13:59:54 +00:00
|
|
|
return cfs_rq->avg.runnable_load_avg;
|
2015-07-15 00:04:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned long cfs_rq_load_avg(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
return cfs_rq->avg.load_avg;
|
|
|
|
}
|
|
|
|
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
static inline unsigned long task_util(struct task_struct *p)
|
|
|
|
{
|
|
|
|
return READ_ONCE(p->se.avg.util_avg);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned long _task_util_est(struct task_struct *p)
|
|
|
|
{
|
|
|
|
struct util_est ue = READ_ONCE(p->se.avg.util_est);
|
|
|
|
|
2018-11-05 14:53:59 +00:00
|
|
|
return (max(ue.ewma, ue.enqueued) | UTIL_AVG_UNCHANGED);
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline unsigned long task_util_est(struct task_struct *p)
|
|
|
|
{
|
|
|
|
return max(task_util(p), _task_util_est(p));
|
|
|
|
}
|
|
|
|
|
2019-12-11 11:38:50 +00:00
|
|
|
#ifdef CONFIG_UCLAMP_TASK
|
|
|
|
static inline unsigned long uclamp_task_util(struct task_struct *p)
|
|
|
|
{
|
|
|
|
return clamp(task_util_est(p),
|
|
|
|
uclamp_eff_value(p, UCLAMP_MIN),
|
|
|
|
uclamp_eff_value(p, UCLAMP_MAX));
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline unsigned long uclamp_task_util(struct task_struct *p)
|
|
|
|
{
|
|
|
|
return task_util_est(p);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
static inline void util_est_enqueue(struct cfs_rq *cfs_rq,
|
|
|
|
struct task_struct *p)
|
|
|
|
{
|
|
|
|
unsigned int enqueued;
|
|
|
|
|
|
|
|
if (!sched_feat(UTIL_EST))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Update root cfs_rq's estimated utilization */
|
|
|
|
enqueued = cfs_rq->avg.util_est.enqueued;
|
2018-11-05 14:53:59 +00:00
|
|
|
enqueued += _task_util_est(p);
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
WRITE_ONCE(cfs_rq->avg.util_est.enqueued, enqueued);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if a (signed) value is within a specified (unsigned) margin,
|
|
|
|
* based on the observation that:
|
|
|
|
*
|
|
|
|
* abs(x) < y := (unsigned)(x + y - 1) < (2 * y - 1)
|
|
|
|
*
|
|
|
|
* NOTE: this only works when value + maring < INT_MAX.
|
|
|
|
*/
|
|
|
|
static inline bool within_margin(int value, int margin)
|
|
|
|
{
|
|
|
|
return ((unsigned int)(value + margin - 1) < (2 * margin - 1));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
util_est_dequeue(struct cfs_rq *cfs_rq, struct task_struct *p, bool task_sleep)
|
|
|
|
{
|
|
|
|
long last_ewma_diff;
|
|
|
|
struct util_est ue;
|
2019-01-23 15:26:54 +00:00
|
|
|
int cpu;
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
|
|
|
|
if (!sched_feat(UTIL_EST))
|
|
|
|
return;
|
|
|
|
|
2018-06-14 10:33:00 +00:00
|
|
|
/* Update root cfs_rq's estimated utilization */
|
|
|
|
ue.enqueued = cfs_rq->avg.util_est.enqueued;
|
2018-11-05 14:53:59 +00:00
|
|
|
ue.enqueued -= min_t(unsigned int, ue.enqueued, _task_util_est(p));
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
WRITE_ONCE(cfs_rq->avg.util_est.enqueued, ue.enqueued);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip update of task's estimated utilization when the task has not
|
|
|
|
* yet completed an activation, e.g. being migrated.
|
|
|
|
*/
|
|
|
|
if (!task_sleep)
|
|
|
|
return;
|
|
|
|
|
2018-03-09 09:52:45 +00:00
|
|
|
/*
|
|
|
|
* If the PELT values haven't changed since enqueue time,
|
|
|
|
* skip the util_est update.
|
|
|
|
*/
|
|
|
|
ue = p->se.avg.util_est;
|
|
|
|
if (ue.enqueued & UTIL_AVG_UNCHANGED)
|
|
|
|
return;
|
|
|
|
|
2019-10-23 20:56:30 +00:00
|
|
|
/*
|
|
|
|
* Reset EWMA on utilization increases, the moving average is used only
|
|
|
|
* to smooth utilization decreases.
|
|
|
|
*/
|
|
|
|
ue.enqueued = (task_util(p) | UTIL_AVG_UNCHANGED);
|
|
|
|
if (sched_feat(UTIL_EST_FASTUP)) {
|
|
|
|
if (ue.ewma < ue.enqueued) {
|
|
|
|
ue.ewma = ue.enqueued;
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
/*
|
|
|
|
* Skip update of task's estimated utilization when its EWMA is
|
|
|
|
* already ~1% close to its last activation value.
|
|
|
|
*/
|
|
|
|
last_ewma_diff = ue.enqueued - ue.ewma;
|
|
|
|
if (within_margin(last_ewma_diff, (SCHED_CAPACITY_SCALE / 100)))
|
|
|
|
return;
|
|
|
|
|
2019-01-23 15:26:54 +00:00
|
|
|
/*
|
|
|
|
* To avoid overestimation of actual task utilization, skip updates if
|
|
|
|
* we cannot grant there is idle time in this CPU.
|
|
|
|
*/
|
|
|
|
cpu = cpu_of(rq_of(cfs_rq));
|
|
|
|
if (task_util(p) > capacity_orig_of(cpu))
|
|
|
|
return;
|
|
|
|
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
/*
|
|
|
|
* Update Task's estimated utilization
|
|
|
|
*
|
|
|
|
* When *p completes an activation we can consolidate another sample
|
|
|
|
* of the task size. This is done by storing the current PELT value
|
|
|
|
* as ue.enqueued and by using this value to update the Exponential
|
|
|
|
* Weighted Moving Average (EWMA):
|
|
|
|
*
|
|
|
|
* ewma(t) = w * task_util(p) + (1-w) * ewma(t-1)
|
|
|
|
* = w * task_util(p) + ewma(t-1) - w * ewma(t-1)
|
|
|
|
* = w * (task_util(p) - ewma(t-1)) + ewma(t-1)
|
|
|
|
* = w * ( last_ewma_diff ) + ewma(t-1)
|
|
|
|
* = w * (last_ewma_diff + ewma(t-1) / w)
|
|
|
|
*
|
|
|
|
* Where 'w' is the weight of new samples, which is configured to be
|
|
|
|
* 0.25, thus making w=1/4 ( >>= UTIL_EST_WEIGHT_SHIFT)
|
|
|
|
*/
|
|
|
|
ue.ewma <<= UTIL_EST_WEIGHT_SHIFT;
|
|
|
|
ue.ewma += last_ewma_diff;
|
|
|
|
ue.ewma >>= UTIL_EST_WEIGHT_SHIFT;
|
2019-10-23 20:56:30 +00:00
|
|
|
done:
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
WRITE_ONCE(p->se.avg.util_est, ue);
|
|
|
|
}
|
|
|
|
|
2018-07-04 10:17:40 +00:00
|
|
|
static inline int task_fits_capacity(struct task_struct *p, long capacity)
|
|
|
|
{
|
2019-12-11 11:38:50 +00:00
|
|
|
return fits_capacity(uclamp_task_util(p), capacity);
|
2018-07-04 10:17:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void update_misfit_status(struct task_struct *p, struct rq *rq)
|
|
|
|
{
|
|
|
|
if (!static_branch_unlikely(&sched_asym_cpucapacity))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!p) {
|
|
|
|
rq->misfit_task_load = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (task_fits_capacity(p, capacity_of(cpu_of(rq)))) {
|
|
|
|
rq->misfit_task_load = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
rq->misfit_task_load = task_h_load(p);
|
|
|
|
}
|
|
|
|
|
2014-01-23 19:32:21 +00:00
|
|
|
#else /* CONFIG_SMP */
|
|
|
|
|
2016-11-08 09:53:44 +00:00
|
|
|
#define UPDATE_TG 0x0
|
|
|
|
#define SKIP_AGE_LOAD 0x0
|
2017-05-06 15:37:03 +00:00
|
|
|
#define DO_ATTACH 0x0
|
2016-11-08 09:53:44 +00:00
|
|
|
|
2017-05-06 15:32:43 +00:00
|
|
|
static inline void update_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se, int not_used1)
|
2016-05-06 12:58:43 +00:00
|
|
|
{
|
2018-02-02 09:27:00 +00:00
|
|
|
cfs_rq_util_change(cfs_rq, 0);
|
2016-05-06 12:58:43 +00:00
|
|
|
}
|
|
|
|
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
static inline void remove_entity_load_avg(struct sched_entity *se) {}
|
2014-02-11 15:11:48 +00:00
|
|
|
|
2015-08-20 11:21:56 +00:00
|
|
|
static inline void
|
2020-01-15 10:20:20 +00:00
|
|
|
attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) {}
|
2015-08-20 11:21:56 +00:00
|
|
|
static inline void
|
|
|
|
detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se) {}
|
|
|
|
|
2016-09-21 13:38:12 +00:00
|
|
|
static inline int idle_balance(struct rq *rq, struct rq_flags *rf)
|
2014-02-11 15:11:48 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
static inline void
|
|
|
|
util_est_enqueue(struct cfs_rq *cfs_rq, struct task_struct *p) {}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
util_est_dequeue(struct cfs_rq *cfs_rq, struct task_struct *p,
|
|
|
|
bool task_sleep) {}
|
2018-07-04 10:17:40 +00:00
|
|
|
static inline void update_misfit_status(struct task_struct *p, struct rq *rq) {}
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
|
2014-01-23 19:32:21 +00:00
|
|
|
#endif /* CONFIG_SMP */
|
2012-10-04 11:18:29 +00:00
|
|
|
|
2007-10-15 15:00:10 +00:00
|
|
|
static void check_spread(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_SCHED_DEBUG
|
|
|
|
s64 d = se->vruntime - cfs_rq->min_vruntime;
|
|
|
|
|
|
|
|
if (d < 0)
|
|
|
|
d = -d;
|
|
|
|
|
|
|
|
if (d > 3*sysctl_sched_latency)
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(cfs_rq->nr_spread_over);
|
2007-10-15 15:00:10 +00:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2007-10-15 15:00:05 +00:00
|
|
|
static void
|
|
|
|
place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial)
|
|
|
|
{
|
2008-10-24 09:06:13 +00:00
|
|
|
u64 vruntime = cfs_rq->min_vruntime;
|
2007-10-15 15:00:05 +00:00
|
|
|
|
2007-11-09 21:39:37 +00:00
|
|
|
/*
|
|
|
|
* The 'current' period is already promised to the current tasks,
|
|
|
|
* however the extra weight of the new task will slow them down a
|
|
|
|
* little, place the new task so that it fits in the slot that
|
|
|
|
* stays open at the end.
|
|
|
|
*/
|
2007-10-15 15:00:05 +00:00
|
|
|
if (initial && sched_feat(START_DEBIT))
|
2008-10-17 17:27:04 +00:00
|
|
|
vruntime += sched_vslice(cfs_rq, se);
|
2007-10-15 15:00:05 +00:00
|
|
|
|
2009-09-18 07:19:25 +00:00
|
|
|
/* sleeps up to a single latency don't count. */
|
2010-03-11 16:17:17 +00:00
|
|
|
if (!initial) {
|
2009-09-18 07:19:25 +00:00
|
|
|
unsigned long thresh = sysctl_sched_latency;
|
2008-06-27 11:41:11 +00:00
|
|
|
|
2009-09-18 07:19:25 +00:00
|
|
|
/*
|
|
|
|
* Halve their sleep time's effect, to allow
|
|
|
|
* for a gentler effect of sleepers:
|
|
|
|
*/
|
|
|
|
if (sched_feat(GENTLE_FAIR_SLEEPERS))
|
|
|
|
thresh >>= 1;
|
2009-09-16 06:54:45 +00:00
|
|
|
|
2009-09-18 07:19:25 +00:00
|
|
|
vruntime -= thresh;
|
2007-10-15 15:00:05 +00:00
|
|
|
}
|
|
|
|
|
sched: Ensure that a child can't gain time over it's parent after fork()
A fork/exec load is usually "pass the baton", so the child
should never be placed behind the parent. With START_DEBIT we
make room for the new task, but with child_runs_first, that
room comes out of the _parent's_ hide. There's nothing to say
that the parent wasn't ahead of min_vruntime at fork() time,
which means that the "baton carrier", who is essentially the
parent in drag, can gain time and increase scheduling latencies
for waiters.
With NEW_FAIR_SLEEPERS + START_DEBIT + child_runs_first
enabled, we essentially pass the sleeper fairness off to the
child, which is fine, but if we don't base placement on the
parent's updated vruntime, we can end up compounding latency
woes if the child itself then does fork/exec. The debit
incurred at fork doesn't hurt the parent who is then going to
sleep and maybe exit, but the child who acquires the error
harms all comers.
This improves latencies of make -j<n> kernel build workloads.
Reported-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-08 09:12:28 +00:00
|
|
|
/* ensure we never gain time by being placed backwards. */
|
2012-11-08 08:03:46 +00:00
|
|
|
se->vruntime = max_vruntime(se->vruntime, vruntime);
|
2007-10-15 15:00:05 +00:00
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:39 +00:00
|
|
|
static void check_enqueue_throttle(struct cfs_rq *cfs_rq);
|
|
|
|
|
2016-02-05 09:08:36 +00:00
|
|
|
static inline void check_schedstat_required(void)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_SCHEDSTATS
|
|
|
|
if (schedstat_enabled())
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Force schedstat enabled if a dependent tracepoint is active */
|
|
|
|
if (trace_sched_stat_wait_enabled() ||
|
|
|
|
trace_sched_stat_sleep_enabled() ||
|
|
|
|
trace_sched_stat_iowait_enabled() ||
|
|
|
|
trace_sched_stat_blocked_enabled() ||
|
|
|
|
trace_sched_stat_runtime_enabled()) {
|
2016-06-13 07:32:09 +00:00
|
|
|
printk_deferred_once("Scheduler tracepoints stat_sleep, stat_iowait, "
|
2016-02-05 09:08:36 +00:00
|
|
|
"stat_blocked and stat_runtime require the "
|
2017-06-09 08:00:29 +00:00
|
|
|
"kernel parameter schedstats=enable or "
|
2016-02-05 09:08:36 +00:00
|
|
|
"kernel.sched_schedstats=1\n");
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2016-05-11 14:10:34 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* MIGRATION
|
|
|
|
*
|
|
|
|
* dequeue
|
|
|
|
* update_curr()
|
|
|
|
* update_min_vruntime()
|
|
|
|
* vruntime -= min_vruntime
|
|
|
|
*
|
|
|
|
* enqueue
|
|
|
|
* update_curr()
|
|
|
|
* update_min_vruntime()
|
|
|
|
* vruntime += min_vruntime
|
|
|
|
*
|
|
|
|
* this way the vruntime transition between RQs is done when both
|
|
|
|
* min_vruntime are up-to-date.
|
|
|
|
*
|
|
|
|
* WAKEUP (remote)
|
|
|
|
*
|
2016-05-10 16:24:37 +00:00
|
|
|
* ->migrate_task_rq_fair() (p->state == TASK_WAKING)
|
2016-05-11 14:10:34 +00:00
|
|
|
* vruntime -= min_vruntime
|
|
|
|
*
|
|
|
|
* enqueue
|
|
|
|
* update_curr()
|
|
|
|
* update_min_vruntime()
|
|
|
|
* vruntime += min_vruntime
|
|
|
|
*
|
|
|
|
* this way we don't have the most up-to-date min_vruntime on the originating
|
|
|
|
* CPU and an up-to-date min_vruntime on the destination CPU.
|
|
|
|
*/
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
static void
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
enqueue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2016-05-11 17:27:56 +00:00
|
|
|
bool renorm = !(flags & ENQUEUE_WAKEUP) || (flags & ENQUEUE_MIGRATED);
|
|
|
|
bool curr = cfs_rq->curr == se;
|
|
|
|
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
/*
|
2016-05-11 17:27:56 +00:00
|
|
|
* If we're the current task, we must renormalise before calling
|
|
|
|
* update_curr().
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
*/
|
2016-05-11 17:27:56 +00:00
|
|
|
if (renorm && curr)
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
se->vruntime += cfs_rq->min_vruntime;
|
|
|
|
|
2016-05-11 17:27:56 +00:00
|
|
|
update_curr(cfs_rq);
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
2016-05-11 17:27:56 +00:00
|
|
|
* Otherwise, renormalise after, such that we're placed at the current
|
|
|
|
* moment in time, instead of some random moment in the past. Being
|
|
|
|
* placed in the past could significantly boost this task to the
|
|
|
|
* fairness detriment of existing tasks.
|
2007-07-09 16:51:58 +00:00
|
|
|
*/
|
2016-05-11 17:27:56 +00:00
|
|
|
if (renorm && !curr)
|
|
|
|
se->vruntime += cfs_rq->min_vruntime;
|
|
|
|
|
2016-12-21 15:50:26 +00:00
|
|
|
/*
|
|
|
|
* When enqueuing a sched_entity, we must:
|
|
|
|
* - Update loads to have both entity and cfs_rq synced with now.
|
|
|
|
* - Add its load to cfs_rq->runnable_avg
|
|
|
|
* - For group_entity, update its weight to reflect the new share of
|
|
|
|
* its group cfs_rq
|
|
|
|
* - Add its new weight to cfs_rq->load.weight
|
|
|
|
*/
|
2017-05-06 15:37:03 +00:00
|
|
|
update_load_avg(cfs_rq, se, UPDATE_TG | DO_ATTACH);
|
2017-05-06 13:59:54 +00:00
|
|
|
update_cfs_group(se);
|
2017-08-24 15:38:30 +00:00
|
|
|
enqueue_runnable_load_avg(cfs_rq, se);
|
2012-12-14 15:20:43 +00:00
|
|
|
account_entity_enqueue(cfs_rq, se);
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2016-06-17 17:43:23 +00:00
|
|
|
if (flags & ENQUEUE_WAKEUP)
|
2007-10-15 15:00:05 +00:00
|
|
|
place_entity(cfs_rq, se, 0);
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2016-02-05 09:08:36 +00:00
|
|
|
check_schedstat_required();
|
2016-06-17 17:43:26 +00:00
|
|
|
update_stats_enqueue(cfs_rq, se, flags);
|
|
|
|
check_spread(cfs_rq, se);
|
2016-05-11 17:27:56 +00:00
|
|
|
if (!curr)
|
2007-10-15 15:00:08 +00:00
|
|
|
__enqueue_entity(cfs_rq, se);
|
2010-11-15 23:47:00 +00:00
|
|
|
se->on_rq = 1;
|
2010-11-15 23:47:01 +00:00
|
|
|
|
2011-07-21 16:43:39 +00:00
|
|
|
if (cfs_rq->nr_running == 1) {
|
2010-11-15 23:47:01 +00:00
|
|
|
list_add_leaf_cfs_rq(cfs_rq);
|
2011-07-21 16:43:39 +00:00
|
|
|
check_enqueue_throttle(cfs_rq);
|
|
|
|
}
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2011-02-01 14:48:37 +00:00
|
|
|
static void __clear_buddies_last(struct sched_entity *se)
|
2008-11-11 10:52:33 +00:00
|
|
|
{
|
2011-02-01 14:48:37 +00:00
|
|
|
for_each_sched_entity(se) {
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
2012-02-11 05:05:00 +00:00
|
|
|
if (cfs_rq->last != se)
|
2011-02-01 14:48:37 +00:00
|
|
|
break;
|
2012-02-11 05:05:00 +00:00
|
|
|
|
|
|
|
cfs_rq->last = NULL;
|
2011-02-01 14:48:37 +00:00
|
|
|
}
|
|
|
|
}
|
2008-11-11 10:52:33 +00:00
|
|
|
|
2011-02-01 14:48:37 +00:00
|
|
|
static void __clear_buddies_next(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
for_each_sched_entity(se) {
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
2012-02-11 05:05:00 +00:00
|
|
|
if (cfs_rq->next != se)
|
2011-02-01 14:48:37 +00:00
|
|
|
break;
|
2012-02-11 05:05:00 +00:00
|
|
|
|
|
|
|
cfs_rq->next = NULL;
|
2011-02-01 14:48:37 +00:00
|
|
|
}
|
2008-11-11 10:52:33 +00:00
|
|
|
}
|
|
|
|
|
2011-02-01 14:51:03 +00:00
|
|
|
static void __clear_buddies_skip(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
for_each_sched_entity(se) {
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
2012-02-11 05:05:00 +00:00
|
|
|
if (cfs_rq->skip != se)
|
2011-02-01 14:51:03 +00:00
|
|
|
break;
|
2012-02-11 05:05:00 +00:00
|
|
|
|
|
|
|
cfs_rq->skip = NULL;
|
2011-02-01 14:51:03 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-01-28 13:51:40 +00:00
|
|
|
static void clear_buddies(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
|
|
|
{
|
2011-02-01 14:48:37 +00:00
|
|
|
if (cfs_rq->last == se)
|
|
|
|
__clear_buddies_last(se);
|
|
|
|
|
|
|
|
if (cfs_rq->next == se)
|
|
|
|
__clear_buddies_next(se);
|
2011-02-01 14:51:03 +00:00
|
|
|
|
|
|
|
if (cfs_rq->skip == se)
|
|
|
|
__clear_buddies_skip(se);
|
2009-01-28 13:51:40 +00:00
|
|
|
}
|
|
|
|
|
2012-03-21 20:07:16 +00:00
|
|
|
static __always_inline void return_cfs_rq_runtime(struct cfs_rq *cfs_rq);
|
2011-07-21 16:43:41 +00:00
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
static void
|
2010-03-24 15:38:48 +00:00
|
|
|
dequeue_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int flags)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2007-10-15 15:00:13 +00:00
|
|
|
/*
|
|
|
|
* Update run-time statistics of the 'current'.
|
|
|
|
*/
|
|
|
|
update_curr(cfs_rq);
|
2016-12-21 15:50:26 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* When dequeuing a sched_entity, we must:
|
|
|
|
* - Update loads to have both entity and cfs_rq synced with now.
|
2018-12-03 09:05:56 +00:00
|
|
|
* - Subtract its load from the cfs_rq->runnable_avg.
|
|
|
|
* - Subtract its previous weight from cfs_rq->load.weight.
|
2016-12-21 15:50:26 +00:00
|
|
|
* - For group entity, update its weight to reflect the new share
|
|
|
|
* of its group cfs_rq.
|
|
|
|
*/
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq, se, UPDATE_TG);
|
2017-08-24 15:38:30 +00:00
|
|
|
dequeue_runnable_load_avg(cfs_rq, se);
|
2007-10-15 15:00:13 +00:00
|
|
|
|
2016-06-17 17:43:26 +00:00
|
|
|
update_stats_dequeue(cfs_rq, se, flags);
|
2007-10-15 15:00:10 +00:00
|
|
|
|
2008-11-11 10:52:33 +00:00
|
|
|
clear_buddies(cfs_rq, se);
|
sched: backward looking buddy
Impact: improve/change/fix wakeup-buddy scheduling
Currently we only have a forward looking buddy, that is, we prefer to
schedule to the task we last woke up, under the presumption that its
going to consume the data we just produced, and therefore will have
cache hot benefits.
This allows co-waking producer/consumer task pairs to run ahead of the
pack for a little while, keeping their cache warm. Without this, we
would interleave all pairs, utterly trashing the cache.
This patch introduces a backward looking buddy, that is, suppose that
in the above scenario, the consumer preempts the producer before it
can go to sleep, we will therefore miss the wakeup from consumer to
producer (its already running, after all), breaking the cycle and
reverting to the cache-trashing interleaved schedule pattern.
The backward buddy will try to schedule back to the task that woke us
up in case the forward buddy is not available, under the assumption
that the last task will be the one with the most cache hot task around
barring current.
This will basically allow a task to continue after it got preempted.
In order to avoid starvation, we allow either buddy to get wakeup_gran
ahead of the pack.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-04 20:25:09 +00:00
|
|
|
|
2007-10-15 15:00:08 +00:00
|
|
|
if (se != cfs_rq->curr)
|
2007-10-15 15:00:07 +00:00
|
|
|
__dequeue_entity(cfs_rq, se);
|
2012-12-14 15:20:43 +00:00
|
|
|
se->on_rq = 0;
|
2007-10-15 15:00:07 +00:00
|
|
|
account_entity_dequeue(cfs_rq, se);
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
|
|
|
|
/*
|
2016-09-20 19:58:12 +00:00
|
|
|
* Normalize after update_curr(); which will also have moved
|
|
|
|
* min_vruntime if @se is the one holding it back. But before doing
|
|
|
|
* update_min_vruntime() again, which will discount @se's position and
|
|
|
|
* can move min_vruntime forward still more.
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
*/
|
2010-03-24 15:38:48 +00:00
|
|
|
if (!(flags & DEQUEUE_SLEEP))
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
se->vruntime -= cfs_rq->min_vruntime;
|
2011-05-17 23:21:10 +00:00
|
|
|
|
2011-07-21 16:43:41 +00:00
|
|
|
/* return excess runtime on last dequeue */
|
|
|
|
return_cfs_rq_runtime(cfs_rq);
|
|
|
|
|
2017-05-06 13:59:54 +00:00
|
|
|
update_cfs_group(se);
|
2016-09-20 19:58:12 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Now advance min_vruntime if @se was the entity holding it back,
|
|
|
|
* except when: DEQUEUE_SAVE && !DEQUEUE_MOVE, in this case we'll be
|
|
|
|
* put back on, and if we advance min_vruntime, we'll be placed back
|
|
|
|
* further than we started -- ie. we'll be penalized.
|
|
|
|
*/
|
2018-10-14 11:26:12 +00:00
|
|
|
if ((flags & (DEQUEUE_SAVE | DEQUEUE_MOVE)) != DEQUEUE_SAVE)
|
2016-09-20 19:58:12 +00:00
|
|
|
update_min_vruntime(cfs_rq);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Preempt the current task with a newly woken task if needed:
|
|
|
|
*/
|
2007-09-05 12:32:49 +00:00
|
|
|
static void
|
2007-10-15 15:00:05 +00:00
|
|
|
check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2007-09-05 12:32:49 +00:00
|
|
|
unsigned long ideal_runtime, delta_exec;
|
2011-09-16 17:35:52 +00:00
|
|
|
struct sched_entity *se;
|
|
|
|
s64 delta;
|
2007-09-05 12:32:49 +00:00
|
|
|
|
2007-10-15 15:00:05 +00:00
|
|
|
ideal_runtime = sched_slice(cfs_rq, curr);
|
2007-09-05 12:32:49 +00:00
|
|
|
delta_exec = curr->sum_exec_runtime - curr->prev_sum_exec_runtime;
|
2009-01-28 13:51:39 +00:00
|
|
|
if (delta_exec > ideal_runtime) {
|
2014-06-28 20:03:57 +00:00
|
|
|
resched_curr(rq_of(cfs_rq));
|
2009-01-28 13:51:39 +00:00
|
|
|
/*
|
|
|
|
* The current task ran long enough, ensure it doesn't get
|
|
|
|
* re-elected due to buddy favours.
|
|
|
|
*/
|
|
|
|
clear_buddies(cfs_rq, curr);
|
sched: Strengthen buddies and mitigate buddy induced latencies
This patch restores the effectiveness of LAST_BUDDY in preventing
pgsql+oltp from collapsing due to wakeup preemption. It also
switches LAST_BUDDY to exclusively do what it does best, namely
mitigate the effects of aggressive wakeup preemption, which
improves vmark throughput markedly, and restores mysql+oltp
scalability.
Since buddies are about scalability, enable them beginning at the
point where we begin expanding sched_latency, namely
sched_nr_latency. Previously, buddies were cleared aggressively,
which seriously reduced their effectiveness. Not clearing
aggressively however, produces a small drop in mysql+oltp
throughput immediately after peak, indicating that LAST_BUDDY is
actually doing some harm. This is right at the point where X on the
desktop in competition with another load wants low latency service.
Ergo, do not enable until we need to scale.
To mitigate latency induced by buddies, or by a task just missing
wakeup preemption, check latency at tick time.
Last hunk prevents buddies from stymieing BALANCE_NEWIDLE via
CACHE_HOT_BUDDY.
Supporting performance tests:
tip = v2.6.32-rc5-1497-ga525b32
tipx = NO_GENTLE_FAIR_SLEEPERS NEXT_BUDDY granularity knobs = 31 knobs + 31 buddies
tip+x = NO_GENTLE_FAIR_SLEEPERS granularity knobs = 31 knobs
(Three run averages except where noted.)
vmark:
------
tip 108466 messages per second
tip+ 125307 messages per second
tip+x 125335 messages per second
tipx 117781 messages per second
2.6.31.3 122729 messages per second
mysql+oltp:
-----------
clients 1 2 4 8 16 32 64 128 256
..........................................................................................
tip 9949.89 18690.20 34801.24 34460.04 32682.88 30765.97 28305.27 25059.64 19548.08
tip+ 10013.90 18526.84 34900.38 34420.14 33069.83 32083.40 30578.30 28010.71 25605.47
tipx 9698.71 18002.70 34477.56 33420.01 32634.30 31657.27 29932.67 26827.52 21487.18
2.6.31.3 8243.11 18784.20 34404.83 33148.38 31900.32 31161.90 29663.81 25995.94 18058.86
pgsql+oltp:
-----------
clients 1 2 4 8 16 32 64 128 256
..........................................................................................
tip 13686.37 26609.25 51934.28 51347.81 49479.51 45312.65 36691.91 26851.57 24145.35
tip+ (1x) 13907.85 27135.87 52951.98 52514.04 51742.52 50705.43 49947.97 48374.19 46227.94
tip+x 13906.78 27065.81 52951.19 52542.59 52176.11 51815.94 50838.90 49439.46 46891.00
tipx 13742.46 26769.81 52351.99 51891.73 51320.79 50938.98 50248.65 48908.70 46553.84
2.6.31.3 13815.35 26906.46 52683.34 52061.31 51937.10 51376.80 50474.28 49394.47 47003.25
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-10-23 21:09:22 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure that a task that missed wakeup preemption by a
|
|
|
|
* narrow margin doesn't have to wait for a full slice.
|
|
|
|
* This also mitigates buddy induced latencies under load.
|
|
|
|
*/
|
|
|
|
if (delta_exec < sysctl_sched_min_granularity)
|
|
|
|
return;
|
|
|
|
|
2011-09-16 17:35:52 +00:00
|
|
|
se = __pick_first_entity(cfs_rq);
|
|
|
|
delta = curr->vruntime - se->vruntime;
|
sched: Strengthen buddies and mitigate buddy induced latencies
This patch restores the effectiveness of LAST_BUDDY in preventing
pgsql+oltp from collapsing due to wakeup preemption. It also
switches LAST_BUDDY to exclusively do what it does best, namely
mitigate the effects of aggressive wakeup preemption, which
improves vmark throughput markedly, and restores mysql+oltp
scalability.
Since buddies are about scalability, enable them beginning at the
point where we begin expanding sched_latency, namely
sched_nr_latency. Previously, buddies were cleared aggressively,
which seriously reduced their effectiveness. Not clearing
aggressively however, produces a small drop in mysql+oltp
throughput immediately after peak, indicating that LAST_BUDDY is
actually doing some harm. This is right at the point where X on the
desktop in competition with another load wants low latency service.
Ergo, do not enable until we need to scale.
To mitigate latency induced by buddies, or by a task just missing
wakeup preemption, check latency at tick time.
Last hunk prevents buddies from stymieing BALANCE_NEWIDLE via
CACHE_HOT_BUDDY.
Supporting performance tests:
tip = v2.6.32-rc5-1497-ga525b32
tipx = NO_GENTLE_FAIR_SLEEPERS NEXT_BUDDY granularity knobs = 31 knobs + 31 buddies
tip+x = NO_GENTLE_FAIR_SLEEPERS granularity knobs = 31 knobs
(Three run averages except where noted.)
vmark:
------
tip 108466 messages per second
tip+ 125307 messages per second
tip+x 125335 messages per second
tipx 117781 messages per second
2.6.31.3 122729 messages per second
mysql+oltp:
-----------
clients 1 2 4 8 16 32 64 128 256
..........................................................................................
tip 9949.89 18690.20 34801.24 34460.04 32682.88 30765.97 28305.27 25059.64 19548.08
tip+ 10013.90 18526.84 34900.38 34420.14 33069.83 32083.40 30578.30 28010.71 25605.47
tipx 9698.71 18002.70 34477.56 33420.01 32634.30 31657.27 29932.67 26827.52 21487.18
2.6.31.3 8243.11 18784.20 34404.83 33148.38 31900.32 31161.90 29663.81 25995.94 18058.86
pgsql+oltp:
-----------
clients 1 2 4 8 16 32 64 128 256
..........................................................................................
tip 13686.37 26609.25 51934.28 51347.81 49479.51 45312.65 36691.91 26851.57 24145.35
tip+ (1x) 13907.85 27135.87 52951.98 52514.04 51742.52 50705.43 49947.97 48374.19 46227.94
tip+x 13906.78 27065.81 52951.19 52542.59 52176.11 51815.94 50838.90 49439.46 46891.00
tipx 13742.46 26769.81 52351.99 51891.73 51320.79 50938.98 50248.65 48908.70 46553.84
2.6.31.3 13815.35 26906.46 52683.34 52061.31 51937.10 51376.80 50474.28 49394.47 47003.25
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-10-23 21:09:22 +00:00
|
|
|
|
2011-09-16 17:35:52 +00:00
|
|
|
if (delta < 0)
|
|
|
|
return;
|
2011-01-05 04:41:17 +00:00
|
|
|
|
2011-09-16 17:35:52 +00:00
|
|
|
if (delta > ideal_runtime)
|
2014-06-28 20:03:57 +00:00
|
|
|
resched_curr(rq_of(cfs_rq));
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2007-10-15 15:00:08 +00:00
|
|
|
static void
|
2007-08-09 09:16:48 +00:00
|
|
|
set_next_entity(struct cfs_rq *cfs_rq, struct sched_entity *se)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2007-10-15 15:00:08 +00:00
|
|
|
/* 'current' is not kept within the tree. */
|
|
|
|
if (se->on_rq) {
|
|
|
|
/*
|
|
|
|
* Any task has to be enqueued before it get to execute on
|
|
|
|
* a CPU. So account for the time it spent waiting on the
|
|
|
|
* runqueue.
|
|
|
|
*/
|
2016-06-17 17:43:26 +00:00
|
|
|
update_stats_wait_end(cfs_rq, se);
|
2007-10-15 15:00:08 +00:00
|
|
|
__dequeue_entity(cfs_rq, se);
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq, se, UPDATE_TG);
|
2007-10-15 15:00:08 +00:00
|
|
|
}
|
|
|
|
|
2007-08-09 09:16:47 +00:00
|
|
|
update_stats_curr_start(cfs_rq, se);
|
2007-10-15 15:00:03 +00:00
|
|
|
cfs_rq->curr = se;
|
2016-06-17 17:43:26 +00:00
|
|
|
|
2007-10-15 15:00:02 +00:00
|
|
|
/*
|
|
|
|
* Track our maximum slice length, if the CPU's load is at
|
|
|
|
* least twice that of our own weight (i.e. dont track it
|
|
|
|
* when there are only lesser-weight tasks around):
|
|
|
|
*/
|
2019-04-24 08:45:56 +00:00
|
|
|
if (schedstat_enabled() &&
|
|
|
|
rq_of(cfs_rq)->cfs.load.weight >= 2*se->load.weight) {
|
2016-06-17 17:43:26 +00:00
|
|
|
schedstat_set(se->statistics.slice_max,
|
|
|
|
max((u64)schedstat_val(se->statistics.slice_max),
|
|
|
|
se->sum_exec_runtime - se->prev_sum_exec_runtime));
|
2007-10-15 15:00:02 +00:00
|
|
|
}
|
2016-06-17 17:43:26 +00:00
|
|
|
|
2007-09-05 12:32:49 +00:00
|
|
|
se->prev_sum_exec_runtime = se->sum_exec_runtime;
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2008-10-24 09:06:16 +00:00
|
|
|
static int
|
|
|
|
wakeup_preempt_entity(struct sched_entity *curr, struct sched_entity *se);
|
|
|
|
|
2011-02-01 14:51:03 +00:00
|
|
|
/*
|
|
|
|
* Pick the next process, keeping these things in mind, in this order:
|
|
|
|
* 1) keep things fair between processes/task groups
|
|
|
|
* 2) pick the "next" process, since someone really wants that to run
|
|
|
|
* 3) pick the "last" process, for cache locality
|
|
|
|
* 4) do not run the "skip" process, if something else is available
|
|
|
|
*/
|
2012-02-11 05:05:00 +00:00
|
|
|
static struct sched_entity *
|
|
|
|
pick_next_entity(struct cfs_rq *cfs_rq, struct sched_entity *curr)
|
2008-03-14 20:12:12 +00:00
|
|
|
{
|
2012-02-11 05:05:00 +00:00
|
|
|
struct sched_entity *left = __pick_first_entity(cfs_rq);
|
|
|
|
struct sched_entity *se;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If curr is set we have to see if its left of the leftmost entity
|
|
|
|
* still in the tree, provided there was anything in the tree at all.
|
|
|
|
*/
|
|
|
|
if (!left || (curr && entity_before(curr, left)))
|
|
|
|
left = curr;
|
|
|
|
|
|
|
|
se = left; /* ideally we run the leftmost entity */
|
2008-11-04 20:25:07 +00:00
|
|
|
|
2011-02-01 14:51:03 +00:00
|
|
|
/*
|
|
|
|
* Avoid running the skip buddy, if running something else can
|
|
|
|
* be done without getting too unfair.
|
|
|
|
*/
|
|
|
|
if (cfs_rq->skip == se) {
|
2012-02-11 05:05:00 +00:00
|
|
|
struct sched_entity *second;
|
|
|
|
|
|
|
|
if (se == curr) {
|
|
|
|
second = __pick_first_entity(cfs_rq);
|
|
|
|
} else {
|
|
|
|
second = __pick_next_entity(se);
|
|
|
|
if (!second || (curr && entity_before(curr, second)))
|
|
|
|
second = curr;
|
|
|
|
}
|
|
|
|
|
2011-02-01 14:51:03 +00:00
|
|
|
if (second && wakeup_preempt_entity(second, left) < 1)
|
|
|
|
se = second;
|
|
|
|
}
|
2008-03-14 20:12:12 +00:00
|
|
|
|
sched: Strengthen buddies and mitigate buddy induced latencies
This patch restores the effectiveness of LAST_BUDDY in preventing
pgsql+oltp from collapsing due to wakeup preemption. It also
switches LAST_BUDDY to exclusively do what it does best, namely
mitigate the effects of aggressive wakeup preemption, which
improves vmark throughput markedly, and restores mysql+oltp
scalability.
Since buddies are about scalability, enable them beginning at the
point where we begin expanding sched_latency, namely
sched_nr_latency. Previously, buddies were cleared aggressively,
which seriously reduced their effectiveness. Not clearing
aggressively however, produces a small drop in mysql+oltp
throughput immediately after peak, indicating that LAST_BUDDY is
actually doing some harm. This is right at the point where X on the
desktop in competition with another load wants low latency service.
Ergo, do not enable until we need to scale.
To mitigate latency induced by buddies, or by a task just missing
wakeup preemption, check latency at tick time.
Last hunk prevents buddies from stymieing BALANCE_NEWIDLE via
CACHE_HOT_BUDDY.
Supporting performance tests:
tip = v2.6.32-rc5-1497-ga525b32
tipx = NO_GENTLE_FAIR_SLEEPERS NEXT_BUDDY granularity knobs = 31 knobs + 31 buddies
tip+x = NO_GENTLE_FAIR_SLEEPERS granularity knobs = 31 knobs
(Three run averages except where noted.)
vmark:
------
tip 108466 messages per second
tip+ 125307 messages per second
tip+x 125335 messages per second
tipx 117781 messages per second
2.6.31.3 122729 messages per second
mysql+oltp:
-----------
clients 1 2 4 8 16 32 64 128 256
..........................................................................................
tip 9949.89 18690.20 34801.24 34460.04 32682.88 30765.97 28305.27 25059.64 19548.08
tip+ 10013.90 18526.84 34900.38 34420.14 33069.83 32083.40 30578.30 28010.71 25605.47
tipx 9698.71 18002.70 34477.56 33420.01 32634.30 31657.27 29932.67 26827.52 21487.18
2.6.31.3 8243.11 18784.20 34404.83 33148.38 31900.32 31161.90 29663.81 25995.94 18058.86
pgsql+oltp:
-----------
clients 1 2 4 8 16 32 64 128 256
..........................................................................................
tip 13686.37 26609.25 51934.28 51347.81 49479.51 45312.65 36691.91 26851.57 24145.35
tip+ (1x) 13907.85 27135.87 52951.98 52514.04 51742.52 50705.43 49947.97 48374.19 46227.94
tip+x 13906.78 27065.81 52951.19 52542.59 52176.11 51815.94 50838.90 49439.46 46891.00
tipx 13742.46 26769.81 52351.99 51891.73 51320.79 50938.98 50248.65 48908.70 46553.84
2.6.31.3 13815.35 26906.46 52683.34 52061.31 51937.10 51376.80 50474.28 49394.47 47003.25
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-10-23 21:09:22 +00:00
|
|
|
/*
|
|
|
|
* Prefer last buddy, try to return the CPU to a preempted task.
|
|
|
|
*/
|
|
|
|
if (cfs_rq->last && wakeup_preempt_entity(cfs_rq->last, left) < 1)
|
|
|
|
se = cfs_rq->last;
|
|
|
|
|
2011-02-01 14:51:03 +00:00
|
|
|
/*
|
|
|
|
* Someone really wants this to run. If it's not unfair, run it.
|
|
|
|
*/
|
|
|
|
if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1)
|
|
|
|
se = cfs_rq->next;
|
|
|
|
|
sched: Strengthen buddies and mitigate buddy induced latencies
This patch restores the effectiveness of LAST_BUDDY in preventing
pgsql+oltp from collapsing due to wakeup preemption. It also
switches LAST_BUDDY to exclusively do what it does best, namely
mitigate the effects of aggressive wakeup preemption, which
improves vmark throughput markedly, and restores mysql+oltp
scalability.
Since buddies are about scalability, enable them beginning at the
point where we begin expanding sched_latency, namely
sched_nr_latency. Previously, buddies were cleared aggressively,
which seriously reduced their effectiveness. Not clearing
aggressively however, produces a small drop in mysql+oltp
throughput immediately after peak, indicating that LAST_BUDDY is
actually doing some harm. This is right at the point where X on the
desktop in competition with another load wants low latency service.
Ergo, do not enable until we need to scale.
To mitigate latency induced by buddies, or by a task just missing
wakeup preemption, check latency at tick time.
Last hunk prevents buddies from stymieing BALANCE_NEWIDLE via
CACHE_HOT_BUDDY.
Supporting performance tests:
tip = v2.6.32-rc5-1497-ga525b32
tipx = NO_GENTLE_FAIR_SLEEPERS NEXT_BUDDY granularity knobs = 31 knobs + 31 buddies
tip+x = NO_GENTLE_FAIR_SLEEPERS granularity knobs = 31 knobs
(Three run averages except where noted.)
vmark:
------
tip 108466 messages per second
tip+ 125307 messages per second
tip+x 125335 messages per second
tipx 117781 messages per second
2.6.31.3 122729 messages per second
mysql+oltp:
-----------
clients 1 2 4 8 16 32 64 128 256
..........................................................................................
tip 9949.89 18690.20 34801.24 34460.04 32682.88 30765.97 28305.27 25059.64 19548.08
tip+ 10013.90 18526.84 34900.38 34420.14 33069.83 32083.40 30578.30 28010.71 25605.47
tipx 9698.71 18002.70 34477.56 33420.01 32634.30 31657.27 29932.67 26827.52 21487.18
2.6.31.3 8243.11 18784.20 34404.83 33148.38 31900.32 31161.90 29663.81 25995.94 18058.86
pgsql+oltp:
-----------
clients 1 2 4 8 16 32 64 128 256
..........................................................................................
tip 13686.37 26609.25 51934.28 51347.81 49479.51 45312.65 36691.91 26851.57 24145.35
tip+ (1x) 13907.85 27135.87 52951.98 52514.04 51742.52 50705.43 49947.97 48374.19 46227.94
tip+x 13906.78 27065.81 52951.19 52542.59 52176.11 51815.94 50838.90 49439.46 46891.00
tipx 13742.46 26769.81 52351.99 51891.73 51320.79 50938.98 50248.65 48908.70 46553.84
2.6.31.3 13815.35 26906.46 52683.34 52061.31 51937.10 51376.80 50474.28 49394.47 47003.25
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-10-23 21:09:22 +00:00
|
|
|
clear_buddies(cfs_rq, se);
|
sched: backward looking buddy
Impact: improve/change/fix wakeup-buddy scheduling
Currently we only have a forward looking buddy, that is, we prefer to
schedule to the task we last woke up, under the presumption that its
going to consume the data we just produced, and therefore will have
cache hot benefits.
This allows co-waking producer/consumer task pairs to run ahead of the
pack for a little while, keeping their cache warm. Without this, we
would interleave all pairs, utterly trashing the cache.
This patch introduces a backward looking buddy, that is, suppose that
in the above scenario, the consumer preempts the producer before it
can go to sleep, we will therefore miss the wakeup from consumer to
producer (its already running, after all), breaking the cycle and
reverting to the cache-trashing interleaved schedule pattern.
The backward buddy will try to schedule back to the task that woke us
up in case the forward buddy is not available, under the assumption
that the last task will be the one with the most cache hot task around
barring current.
This will basically allow a task to continue after it got preempted.
In order to avoid starvation, we allow either buddy to get wakeup_gran
ahead of the pack.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-11-04 20:25:09 +00:00
|
|
|
|
|
|
|
return se;
|
2008-03-14 20:12:12 +00:00
|
|
|
}
|
|
|
|
|
2012-02-11 05:05:00 +00:00
|
|
|
static bool check_cfs_rq_runtime(struct cfs_rq *cfs_rq);
|
2011-07-21 16:43:39 +00:00
|
|
|
|
2007-08-09 09:16:48 +00:00
|
|
|
static void put_prev_entity(struct cfs_rq *cfs_rq, struct sched_entity *prev)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If still on the runqueue then deactivate_task()
|
|
|
|
* was not called and update_curr() has to be done:
|
|
|
|
*/
|
|
|
|
if (prev->on_rq)
|
2007-08-09 09:16:47 +00:00
|
|
|
update_curr(cfs_rq);
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2011-07-21 16:43:39 +00:00
|
|
|
/* throttle cfs_rqs exceeding runtime */
|
|
|
|
check_cfs_rq_runtime(cfs_rq);
|
|
|
|
|
2016-06-17 17:43:26 +00:00
|
|
|
check_spread(cfs_rq, prev);
|
2016-02-05 09:08:36 +00:00
|
|
|
|
2007-10-15 15:00:07 +00:00
|
|
|
if (prev->on_rq) {
|
2016-06-17 17:43:26 +00:00
|
|
|
update_stats_wait_start(cfs_rq, prev);
|
2007-10-15 15:00:07 +00:00
|
|
|
/* Put 'current' back into the tree. */
|
|
|
|
__enqueue_entity(cfs_rq, prev);
|
2012-10-04 11:18:29 +00:00
|
|
|
/* in !on_rq case, update occurred at dequeue */
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq, prev, 0);
|
2007-10-15 15:00:07 +00:00
|
|
|
}
|
2007-10-15 15:00:03 +00:00
|
|
|
cfs_rq->curr = NULL;
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2008-01-25 20:08:29 +00:00
|
|
|
static void
|
|
|
|
entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
|
|
|
/*
|
2007-10-15 15:00:07 +00:00
|
|
|
* Update run-time statistics of the 'current'.
|
2007-07-09 16:51:58 +00:00
|
|
|
*/
|
2007-10-15 15:00:07 +00:00
|
|
|
update_curr(cfs_rq);
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2012-10-04 11:18:29 +00:00
|
|
|
/*
|
|
|
|
* Ensure that runnable average is periodically updated.
|
|
|
|
*/
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq, curr, UPDATE_TG);
|
2017-05-06 13:59:54 +00:00
|
|
|
update_cfs_group(curr);
|
2012-10-04 11:18:29 +00:00
|
|
|
|
2008-01-25 20:08:29 +00:00
|
|
|
#ifdef CONFIG_SCHED_HRTICK
|
|
|
|
/*
|
|
|
|
* queued ticks are scheduled to match the slice, so don't bother
|
|
|
|
* validating it and just reschedule.
|
|
|
|
*/
|
2008-04-25 01:17:55 +00:00
|
|
|
if (queued) {
|
2014-06-28 20:03:57 +00:00
|
|
|
resched_curr(rq_of(cfs_rq));
|
2008-04-25 01:17:55 +00:00
|
|
|
return;
|
|
|
|
}
|
2008-01-25 20:08:29 +00:00
|
|
|
/*
|
|
|
|
* don't let the period tick interfere with the hrtick preemption
|
|
|
|
*/
|
|
|
|
if (!sched_feat(DOUBLE_TICK) &&
|
|
|
|
hrtimer_active(&rq_of(cfs_rq)->hrtick_timer))
|
|
|
|
return;
|
|
|
|
#endif
|
|
|
|
|
2011-07-29 08:20:33 +00:00
|
|
|
if (cfs_rq->nr_running > 1)
|
2007-10-15 15:00:05 +00:00
|
|
|
check_preempt_tick(cfs_rq, curr);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:28 +00:00
|
|
|
|
|
|
|
/**************************************************
|
|
|
|
* CFS bandwidth control machinery
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef CONFIG_CFS_BANDWIDTH
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2018-12-30 15:14:15 +00:00
|
|
|
#ifdef CONFIG_JUMP_LABEL
|
2012-02-24 07:31:31 +00:00
|
|
|
static struct static_key __cfs_bandwidth_used;
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
static inline bool cfs_bandwidth_used(void)
|
|
|
|
{
|
2012-02-24 07:31:31 +00:00
|
|
|
return static_key_false(&__cfs_bandwidth_used);
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
2013-10-16 18:16:12 +00:00
|
|
|
void cfs_bandwidth_usage_inc(void)
|
2011-10-25 08:00:11 +00:00
|
|
|
{
|
2018-01-22 21:53:28 +00:00
|
|
|
static_key_slow_inc_cpuslocked(&__cfs_bandwidth_used);
|
2013-10-16 18:16:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void cfs_bandwidth_usage_dec(void)
|
|
|
|
{
|
2018-01-22 21:53:28 +00:00
|
|
|
static_key_slow_dec_cpuslocked(&__cfs_bandwidth_used);
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
2018-12-30 15:14:15 +00:00
|
|
|
#else /* CONFIG_JUMP_LABEL */
|
2011-10-25 08:00:11 +00:00
|
|
|
static bool cfs_bandwidth_used(void)
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-10-16 18:16:12 +00:00
|
|
|
void cfs_bandwidth_usage_inc(void) {}
|
|
|
|
void cfs_bandwidth_usage_dec(void) {}
|
2018-12-30 15:14:15 +00:00
|
|
|
#endif /* CONFIG_JUMP_LABEL */
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2011-07-21 16:43:28 +00:00
|
|
|
/*
|
|
|
|
* default period for cfs group bandwidth.
|
|
|
|
* default: 0.1s, units: nanoseconds
|
|
|
|
*/
|
|
|
|
static inline u64 default_cfs_period(void)
|
|
|
|
{
|
|
|
|
return 100000000ULL;
|
|
|
|
}
|
2011-07-21 16:43:30 +00:00
|
|
|
|
|
|
|
static inline u64 sched_cfs_bandwidth_slice(void)
|
|
|
|
{
|
|
|
|
return (u64)sysctl_sched_cfs_bandwidth_slice * NSEC_PER_USEC;
|
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:32 +00:00
|
|
|
/*
|
2019-08-20 18:40:55 +00:00
|
|
|
* Replenish runtime according to assigned quota. We use sched_clock_cpu
|
|
|
|
* directly instead of rq->clock to avoid adding additional synchronization
|
|
|
|
* around rq->lock.
|
2011-07-21 16:43:32 +00:00
|
|
|
*
|
|
|
|
* requires cfs_b->lock
|
|
|
|
*/
|
2011-10-25 08:00:11 +00:00
|
|
|
void __refill_cfs_bandwidth_runtime(struct cfs_bandwidth *cfs_b)
|
2011-07-21 16:43:32 +00:00
|
|
|
{
|
2019-08-20 18:40:55 +00:00
|
|
|
if (cfs_b->quota != RUNTIME_INF)
|
|
|
|
cfs_b->runtime = cfs_b->quota;
|
2011-07-21 16:43:32 +00:00
|
|
|
}
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
static inline struct cfs_bandwidth *tg_cfs_bandwidth(struct task_group *tg)
|
|
|
|
{
|
|
|
|
return &tg->cfs_bandwidth;
|
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:33 +00:00
|
|
|
/* returns 0 on failure to allocate runtime */
|
|
|
|
static int assign_cfs_rq_runtime(struct cfs_rq *cfs_rq)
|
2011-07-21 16:43:30 +00:00
|
|
|
{
|
|
|
|
struct task_group *tg = cfs_rq->tg;
|
|
|
|
struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(tg);
|
sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
It has been observed, that highly-threaded, non-cpu-bound applications
running under cpu.cfs_quota_us constraints can hit a high percentage of
periods throttled while simultaneously not consuming the allocated
amount of quota. This use case is typical of user-interactive non-cpu
bound applications, such as those running in kubernetes or mesos when
run on multiple cpu cores.
This has been root caused to cpu-local run queue being allocated per cpu
bandwidth slices, and then not fully using that slice within the period.
At which point the slice and quota expires. This expiration of unused
slice results in applications not being able to utilize the quota for
which they are allocated.
The non-expiration of per-cpu slices was recently fixed by
'commit 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift
condition")'. Prior to that it appears that this had been broken since
at least 'commit 51f2176d74ac ("sched/fair: Fix unlocked reads of some
cfs_b->quota/period")' which was introduced in v3.16-rc1 in 2014. That
added the following conditional which resulted in slices never being
expired.
if (cfs_rq->runtime_expires != cfs_b->runtime_expires) {
/* extend local deadline, drift is bounded above by 2 ticks */
cfs_rq->runtime_expires += TICK_NSEC;
Because this was broken for nearly 5 years, and has recently been fixed
and is now being noticed by many users running kubernetes
(https://github.com/kubernetes/kubernetes/issues/67577) it is my opinion
that the mechanisms around expiring runtime should be removed
altogether.
This allows quota already allocated to per-cpu run-queues to live longer
than the period boundary. This allows threads on runqueues that do not
use much CPU to continue to use their remaining slice over a longer
period of time than cpu.cfs_period_us. However, this helps prevent the
above condition of hitting throttling while also not fully utilizing
your cpu quota.
This theoretically allows a machine to use slightly more than its
allotted quota in some periods. This overflow would be bounded by the
remaining quota left on each per-cpu runqueueu. This is typically no
more than min_cfs_rq_runtime=1ms per cpu. For CPU bound tasks this will
change nothing, as they should theoretically fully utilize all of their
quota in each period. For user-interactive tasks as described above this
provides a much better user/application experience as their cpu
utilization will more closely match the amount they requested when they
hit throttling. This means that cpu limits no longer strictly apply per
period for non-cpu bound applications, but that they are still accurate
over longer timeframes.
This greatly improves performance of high-thread-count, non-cpu bound
applications with low cfs_quota_us allocation on high-core-count
machines. In the case of an artificial testcase (10ms/100ms of quota on
80 CPU machine), this commit resulted in almost 30x performance
improvement, while still maintaining correct cpu quota restrictions.
That testcase is available at https://github.com/indeedeng/fibtest.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Signed-off-by: Dave Chiluk <chiluk+linux@indeed.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: John Hammond <jhammond@indeed.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kyle Anderson <kwa@yelp.com>
Cc: Gabriel Munos <gmunoz@netflix.com>
Cc: Peter Oskolkov <posk@posk.io>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Brendan Gregg <bgregg@netflix.com>
Link: https://lkml.kernel.org/r/1563900266-19734-2-git-send-email-chiluk+linux@indeed.com
2019-07-23 16:44:26 +00:00
|
|
|
u64 amount = 0, min_amount;
|
2011-07-21 16:43:30 +00:00
|
|
|
|
|
|
|
/* note: this is a positive sum as runtime_remaining <= 0 */
|
|
|
|
min_amount = sched_cfs_bandwidth_slice() - cfs_rq->runtime_remaining;
|
|
|
|
|
|
|
|
raw_spin_lock(&cfs_b->lock);
|
|
|
|
if (cfs_b->quota == RUNTIME_INF)
|
|
|
|
amount = min_amount;
|
2011-07-21 16:43:31 +00:00
|
|
|
else {
|
sched: Cleanup bandwidth timers
Roman reported a 3 cpu lockup scenario involving __start_cfs_bandwidth().
The more I look at that code the more I'm convinced its crack, that
entire __start_cfs_bandwidth() thing is brain melting, we don't need to
cancel a timer before starting it, *hrtimer_start*() will happily remove
the timer for you if its still enqueued.
Removing that, removes a big part of the problem, no more ugly cancel
loop to get stuck in.
So now, if I understand things right, the entire reason you have this
cfs_b->lock guarded ->timer_active nonsense is to make sure we don't
accidentally lose the timer.
It appears to me that it should be possible to guarantee that same by
unconditionally (re)starting the timer when !queued. Because regardless
what hrtimer::function will return, if we beat it to (re)enqueue the
timer, it doesn't matter.
Now, because hrtimers don't come with any serialization guarantees we
must ensure both handler and (re)start loop serialize their access to
the hrtimer to avoid both trying to forward the timer at the same
time.
Update the rt bandwidth timer to match.
This effectively reverts: 09dc4ab03936 ("sched/fair: Fix
tg_set_cfs_bandwidth() deadlock on rq->lock").
Reported-by: Roman Gushchin <klamm@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Paul Turner <pjt@google.com>
Link: http://lkml.kernel.org/r/20150415095011.804589208@infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-04-15 09:41:57 +00:00
|
|
|
start_cfs_bandwidth(cfs_b);
|
2011-07-21 16:43:31 +00:00
|
|
|
|
|
|
|
if (cfs_b->runtime > 0) {
|
|
|
|
amount = min(cfs_b->runtime, min_amount);
|
|
|
|
cfs_b->runtime -= amount;
|
|
|
|
cfs_b->idle = 0;
|
|
|
|
}
|
2011-07-21 16:43:30 +00:00
|
|
|
}
|
|
|
|
raw_spin_unlock(&cfs_b->lock);
|
|
|
|
|
|
|
|
cfs_rq->runtime_remaining += amount;
|
2011-07-21 16:43:33 +00:00
|
|
|
|
|
|
|
return cfs_rq->runtime_remaining > 0;
|
2011-07-21 16:43:30 +00:00
|
|
|
}
|
|
|
|
|
2013-11-18 17:27:06 +00:00
|
|
|
static void __account_cfs_rq_runtime(struct cfs_rq *cfs_rq, u64 delta_exec)
|
2011-07-21 16:43:32 +00:00
|
|
|
{
|
|
|
|
/* dock delta_exec before expiring quota (as it could span periods) */
|
2011-07-21 16:43:30 +00:00
|
|
|
cfs_rq->runtime_remaining -= delta_exec;
|
2011-07-21 16:43:32 +00:00
|
|
|
|
|
|
|
if (likely(cfs_rq->runtime_remaining > 0))
|
2011-07-21 16:43:30 +00:00
|
|
|
return;
|
|
|
|
|
2019-08-26 12:16:33 +00:00
|
|
|
if (cfs_rq->throttled)
|
|
|
|
return;
|
2011-07-21 16:43:33 +00:00
|
|
|
/*
|
|
|
|
* if we're unable to extend our runtime we resched so that the active
|
|
|
|
* hierarchy can be throttled
|
|
|
|
*/
|
|
|
|
if (!assign_cfs_rq_runtime(cfs_rq) && likely(cfs_rq->curr))
|
2014-06-28 20:03:57 +00:00
|
|
|
resched_curr(rq_of(cfs_rq));
|
2011-07-21 16:43:30 +00:00
|
|
|
}
|
|
|
|
|
2012-03-21 20:07:16 +00:00
|
|
|
static __always_inline
|
2013-11-18 17:27:06 +00:00
|
|
|
void account_cfs_rq_runtime(struct cfs_rq *cfs_rq, u64 delta_exec)
|
2011-07-21 16:43:30 +00:00
|
|
|
{
|
2011-11-08 04:26:33 +00:00
|
|
|
if (!cfs_bandwidth_used() || !cfs_rq->runtime_enabled)
|
2011-07-21 16:43:30 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
__account_cfs_rq_runtime(cfs_rq, delta_exec);
|
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:33 +00:00
|
|
|
static inline int cfs_rq_throttled(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
2011-11-08 04:26:33 +00:00
|
|
|
return cfs_bandwidth_used() && cfs_rq->throttled;
|
2011-07-21 16:43:33 +00:00
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:36 +00:00
|
|
|
/* check whether cfs_rq, or any parent, is throttled */
|
|
|
|
static inline int throttled_hierarchy(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
2011-11-08 04:26:33 +00:00
|
|
|
return cfs_bandwidth_used() && cfs_rq->throttle_count;
|
2011-07-21 16:43:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure that neither of the group entities corresponding to src_cpu or
|
|
|
|
* dest_cpu are members of a throttled hierarchy when performing group
|
|
|
|
* load-balance operations.
|
|
|
|
*/
|
|
|
|
static inline int throttled_lb_pair(struct task_group *tg,
|
|
|
|
int src_cpu, int dest_cpu)
|
|
|
|
{
|
|
|
|
struct cfs_rq *src_cfs_rq, *dest_cfs_rq;
|
|
|
|
|
|
|
|
src_cfs_rq = tg->cfs_rq[src_cpu];
|
|
|
|
dest_cfs_rq = tg->cfs_rq[dest_cpu];
|
|
|
|
|
|
|
|
return throttled_hierarchy(src_cfs_rq) ||
|
|
|
|
throttled_hierarchy(dest_cfs_rq);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int tg_unthrottle_up(struct task_group *tg, void *data)
|
|
|
|
{
|
|
|
|
struct rq *rq = data;
|
|
|
|
struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)];
|
|
|
|
|
|
|
|
cfs_rq->throttle_count--;
|
|
|
|
if (!cfs_rq->throttle_count) {
|
2013-04-11 23:51:02 +00:00
|
|
|
cfs_rq->throttled_clock_task_time += rq_clock_task(rq) -
|
2012-10-04 11:18:31 +00:00
|
|
|
cfs_rq->throttled_clock_task;
|
2019-02-06 16:14:21 +00:00
|
|
|
|
|
|
|
/* Add cfs_rq with already running entity in the list */
|
|
|
|
if (cfs_rq->nr_running >= 1)
|
|
|
|
list_add_leaf_cfs_rq(cfs_rq);
|
2011-07-21 16:43:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int tg_throttle_down(struct task_group *tg, void *data)
|
|
|
|
{
|
|
|
|
struct rq *rq = data;
|
|
|
|
struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)];
|
|
|
|
|
2012-10-04 11:18:31 +00:00
|
|
|
/* group is entering throttled state, stop time */
|
2019-02-06 16:14:21 +00:00
|
|
|
if (!cfs_rq->throttle_count) {
|
2013-04-11 23:51:02 +00:00
|
|
|
cfs_rq->throttled_clock_task = rq_clock_task(rq);
|
2019-02-06 16:14:21 +00:00
|
|
|
list_del_leaf_cfs_rq(cfs_rq);
|
|
|
|
}
|
2011-07-21 16:43:36 +00:00
|
|
|
cfs_rq->throttle_count++;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:39 +00:00
|
|
|
static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
|
2011-07-21 16:43:33 +00:00
|
|
|
{
|
|
|
|
struct rq *rq = rq_of(cfs_rq);
|
|
|
|
struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(cfs_rq->tg);
|
|
|
|
struct sched_entity *se;
|
2019-06-26 05:06:29 +00:00
|
|
|
long task_delta, idle_task_delta, dequeue = 1;
|
sched: Cleanup bandwidth timers
Roman reported a 3 cpu lockup scenario involving __start_cfs_bandwidth().
The more I look at that code the more I'm convinced its crack, that
entire __start_cfs_bandwidth() thing is brain melting, we don't need to
cancel a timer before starting it, *hrtimer_start*() will happily remove
the timer for you if its still enqueued.
Removing that, removes a big part of the problem, no more ugly cancel
loop to get stuck in.
So now, if I understand things right, the entire reason you have this
cfs_b->lock guarded ->timer_active nonsense is to make sure we don't
accidentally lose the timer.
It appears to me that it should be possible to guarantee that same by
unconditionally (re)starting the timer when !queued. Because regardless
what hrtimer::function will return, if we beat it to (re)enqueue the
timer, it doesn't matter.
Now, because hrtimers don't come with any serialization guarantees we
must ensure both handler and (re)start loop serialize their access to
the hrtimer to avoid both trying to forward the timer at the same
time.
Update the rt bandwidth timer to match.
This effectively reverts: 09dc4ab03936 ("sched/fair: Fix
tg_set_cfs_bandwidth() deadlock on rq->lock").
Reported-by: Roman Gushchin <klamm@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Paul Turner <pjt@google.com>
Link: http://lkml.kernel.org/r/20150415095011.804589208@infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-04-15 09:41:57 +00:00
|
|
|
bool empty;
|
2011-07-21 16:43:33 +00:00
|
|
|
|
|
|
|
se = cfs_rq->tg->se[cpu_of(rq_of(cfs_rq))];
|
|
|
|
|
2012-10-04 11:18:31 +00:00
|
|
|
/* freeze hierarchy runnable averages while throttled */
|
2011-07-21 16:43:36 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
walk_tg_tree_from(cfs_rq->tg, tg_throttle_down, tg_nop, (void *)rq);
|
|
|
|
rcu_read_unlock();
|
2011-07-21 16:43:33 +00:00
|
|
|
|
|
|
|
task_delta = cfs_rq->h_nr_running;
|
2019-06-26 05:06:29 +00:00
|
|
|
idle_task_delta = cfs_rq->idle_h_nr_running;
|
2011-07-21 16:43:33 +00:00
|
|
|
for_each_sched_entity(se) {
|
|
|
|
struct cfs_rq *qcfs_rq = cfs_rq_of(se);
|
|
|
|
/* throttled entity or throttle-on-deactivate */
|
|
|
|
if (!se->on_rq)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (dequeue)
|
|
|
|
dequeue_entity(qcfs_rq, se, DEQUEUE_SLEEP);
|
|
|
|
qcfs_rq->h_nr_running -= task_delta;
|
2019-06-26 05:06:29 +00:00
|
|
|
qcfs_rq->idle_h_nr_running -= idle_task_delta;
|
2011-07-21 16:43:33 +00:00
|
|
|
|
|
|
|
if (qcfs_rq->load.weight)
|
|
|
|
dequeue = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!se)
|
2014-05-08 23:00:14 +00:00
|
|
|
sub_nr_running(rq, task_delta);
|
2011-07-21 16:43:33 +00:00
|
|
|
|
|
|
|
cfs_rq->throttled = 1;
|
2013-04-11 23:51:02 +00:00
|
|
|
cfs_rq->throttled_clock = rq_clock(rq);
|
2011-07-21 16:43:33 +00:00
|
|
|
raw_spin_lock(&cfs_b->lock);
|
2015-06-24 19:41:47 +00:00
|
|
|
empty = list_empty(&cfs_b->throttled_cfs_rq);
|
sched: Cleanup bandwidth timers
Roman reported a 3 cpu lockup scenario involving __start_cfs_bandwidth().
The more I look at that code the more I'm convinced its crack, that
entire __start_cfs_bandwidth() thing is brain melting, we don't need to
cancel a timer before starting it, *hrtimer_start*() will happily remove
the timer for you if its still enqueued.
Removing that, removes a big part of the problem, no more ugly cancel
loop to get stuck in.
So now, if I understand things right, the entire reason you have this
cfs_b->lock guarded ->timer_active nonsense is to make sure we don't
accidentally lose the timer.
It appears to me that it should be possible to guarantee that same by
unconditionally (re)starting the timer when !queued. Because regardless
what hrtimer::function will return, if we beat it to (re)enqueue the
timer, it doesn't matter.
Now, because hrtimers don't come with any serialization guarantees we
must ensure both handler and (re)start loop serialize their access to
the hrtimer to avoid both trying to forward the timer at the same
time.
Update the rt bandwidth timer to match.
This effectively reverts: 09dc4ab03936 ("sched/fair: Fix
tg_set_cfs_bandwidth() deadlock on rq->lock").
Reported-by: Roman Gushchin <klamm@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Paul Turner <pjt@google.com>
Link: http://lkml.kernel.org/r/20150415095011.804589208@infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-04-15 09:41:57 +00:00
|
|
|
|
sched: Fix potential near-infinite distribute_cfs_runtime() loop
distribute_cfs_runtime() intentionally only hands out enough runtime to
bring each cfs_rq to 1 ns of runtime, expecting the cfs_rqs to then take
the runtime they need only once they actually get to run. However, if
they get to run sufficiently quickly, the period timer is still in
distribute_cfs_runtime() and no runtime is available, causing them to
throttle. Then distribute has to handle them again, and this can go on
until distribute has handed out all of the runtime 1ns at a time, which
takes far too long.
Instead allow access to the same runtime that distribute is handing out,
accepting that corner cases with very low quota may be able to spend the
entire cfs_b->runtime during distribute_cfs_runtime, meaning that the
runtime directly handed out by distribute_cfs_runtime was over quota. In
addition, if a cfs_rq does manage to throttle like this, make sure the
existing distribute_cfs_runtime no longer loops over it again.
Signed-off-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140620222120.13814.21652.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-06-20 22:21:20 +00:00
|
|
|
/*
|
|
|
|
* Add to the _head_ of the list, so that an already-started
|
sched/fair: Fix throttle_list starvation with low CFS quota
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve. Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list. The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
Signed-off-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-10-08 14:36:40 +00:00
|
|
|
* distribute_cfs_runtime will not see us. If disribute_cfs_runtime is
|
|
|
|
* not running add to the tail so that later runqueues don't get starved.
|
sched: Fix potential near-infinite distribute_cfs_runtime() loop
distribute_cfs_runtime() intentionally only hands out enough runtime to
bring each cfs_rq to 1 ns of runtime, expecting the cfs_rqs to then take
the runtime they need only once they actually get to run. However, if
they get to run sufficiently quickly, the period timer is still in
distribute_cfs_runtime() and no runtime is available, causing them to
throttle. Then distribute has to handle them again, and this can go on
until distribute has handed out all of the runtime 1ns at a time, which
takes far too long.
Instead allow access to the same runtime that distribute is handing out,
accepting that corner cases with very low quota may be able to spend the
entire cfs_b->runtime during distribute_cfs_runtime, meaning that the
runtime directly handed out by distribute_cfs_runtime was over quota. In
addition, if a cfs_rq does manage to throttle like this, make sure the
existing distribute_cfs_runtime no longer loops over it again.
Signed-off-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140620222120.13814.21652.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-06-20 22:21:20 +00:00
|
|
|
*/
|
sched/fair: Fix throttle_list starvation with low CFS quota
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve. Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list. The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
Signed-off-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-10-08 14:36:40 +00:00
|
|
|
if (cfs_b->distribute_running)
|
|
|
|
list_add_rcu(&cfs_rq->throttled_list, &cfs_b->throttled_cfs_rq);
|
|
|
|
else
|
|
|
|
list_add_tail_rcu(&cfs_rq->throttled_list, &cfs_b->throttled_cfs_rq);
|
sched: Cleanup bandwidth timers
Roman reported a 3 cpu lockup scenario involving __start_cfs_bandwidth().
The more I look at that code the more I'm convinced its crack, that
entire __start_cfs_bandwidth() thing is brain melting, we don't need to
cancel a timer before starting it, *hrtimer_start*() will happily remove
the timer for you if its still enqueued.
Removing that, removes a big part of the problem, no more ugly cancel
loop to get stuck in.
So now, if I understand things right, the entire reason you have this
cfs_b->lock guarded ->timer_active nonsense is to make sure we don't
accidentally lose the timer.
It appears to me that it should be possible to guarantee that same by
unconditionally (re)starting the timer when !queued. Because regardless
what hrtimer::function will return, if we beat it to (re)enqueue the
timer, it doesn't matter.
Now, because hrtimers don't come with any serialization guarantees we
must ensure both handler and (re)start loop serialize their access to
the hrtimer to avoid both trying to forward the timer at the same
time.
Update the rt bandwidth timer to match.
This effectively reverts: 09dc4ab03936 ("sched/fair: Fix
tg_set_cfs_bandwidth() deadlock on rq->lock").
Reported-by: Roman Gushchin <klamm@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Paul Turner <pjt@google.com>
Link: http://lkml.kernel.org/r/20150415095011.804589208@infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-04-15 09:41:57 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we're the first throttled task, make sure the bandwidth
|
|
|
|
* timer is running.
|
|
|
|
*/
|
|
|
|
if (empty)
|
|
|
|
start_cfs_bandwidth(cfs_b);
|
|
|
|
|
2011-07-21 16:43:33 +00:00
|
|
|
raw_spin_unlock(&cfs_b->lock);
|
|
|
|
}
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
|
2011-07-21 16:43:34 +00:00
|
|
|
{
|
|
|
|
struct rq *rq = rq_of(cfs_rq);
|
|
|
|
struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(cfs_rq->tg);
|
|
|
|
struct sched_entity *se;
|
|
|
|
int enqueue = 1;
|
2019-06-26 05:06:29 +00:00
|
|
|
long task_delta, idle_task_delta;
|
2011-07-21 16:43:34 +00:00
|
|
|
|
2013-06-04 06:23:39 +00:00
|
|
|
se = cfs_rq->tg->se[cpu_of(rq)];
|
2011-07-21 16:43:34 +00:00
|
|
|
|
|
|
|
cfs_rq->throttled = 0;
|
2013-04-11 23:51:01 +00:00
|
|
|
|
|
|
|
update_rq_clock(rq);
|
|
|
|
|
2011-07-21 16:43:34 +00:00
|
|
|
raw_spin_lock(&cfs_b->lock);
|
2013-04-11 23:51:02 +00:00
|
|
|
cfs_b->throttled_time += rq_clock(rq) - cfs_rq->throttled_clock;
|
2011-07-21 16:43:34 +00:00
|
|
|
list_del_rcu(&cfs_rq->throttled_list);
|
|
|
|
raw_spin_unlock(&cfs_b->lock);
|
|
|
|
|
2011-07-21 16:43:36 +00:00
|
|
|
/* update hierarchical throttle state */
|
|
|
|
walk_tg_tree_from(cfs_rq->tg, tg_nop, tg_unthrottle_up, (void *)rq);
|
|
|
|
|
2011-07-21 16:43:34 +00:00
|
|
|
if (!cfs_rq->load.weight)
|
|
|
|
return;
|
|
|
|
|
|
|
|
task_delta = cfs_rq->h_nr_running;
|
2019-06-26 05:06:29 +00:00
|
|
|
idle_task_delta = cfs_rq->idle_h_nr_running;
|
2011-07-21 16:43:34 +00:00
|
|
|
for_each_sched_entity(se) {
|
|
|
|
if (se->on_rq)
|
|
|
|
enqueue = 0;
|
|
|
|
|
|
|
|
cfs_rq = cfs_rq_of(se);
|
|
|
|
if (enqueue)
|
|
|
|
enqueue_entity(cfs_rq, se, ENQUEUE_WAKEUP);
|
|
|
|
cfs_rq->h_nr_running += task_delta;
|
2019-06-26 05:06:29 +00:00
|
|
|
cfs_rq->idle_h_nr_running += idle_task_delta;
|
2011-07-21 16:43:34 +00:00
|
|
|
|
|
|
|
if (cfs_rq_throttled(cfs_rq))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-02-06 16:14:21 +00:00
|
|
|
assert_list_leaf_cfs_rq(rq);
|
|
|
|
|
2011-07-21 16:43:34 +00:00
|
|
|
if (!se)
|
2014-05-08 23:00:14 +00:00
|
|
|
add_nr_running(rq, task_delta);
|
2011-07-21 16:43:34 +00:00
|
|
|
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/* Determine whether we need to wake up potentially idle CPU: */
|
2011-07-21 16:43:34 +00:00
|
|
|
if (rq->curr == rq->idle && rq->cfs.nr_running)
|
2014-06-28 20:03:57 +00:00
|
|
|
resched_curr(rq);
|
2011-07-21 16:43:34 +00:00
|
|
|
}
|
|
|
|
|
sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
It has been observed, that highly-threaded, non-cpu-bound applications
running under cpu.cfs_quota_us constraints can hit a high percentage of
periods throttled while simultaneously not consuming the allocated
amount of quota. This use case is typical of user-interactive non-cpu
bound applications, such as those running in kubernetes or mesos when
run on multiple cpu cores.
This has been root caused to cpu-local run queue being allocated per cpu
bandwidth slices, and then not fully using that slice within the period.
At which point the slice and quota expires. This expiration of unused
slice results in applications not being able to utilize the quota for
which they are allocated.
The non-expiration of per-cpu slices was recently fixed by
'commit 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift
condition")'. Prior to that it appears that this had been broken since
at least 'commit 51f2176d74ac ("sched/fair: Fix unlocked reads of some
cfs_b->quota/period")' which was introduced in v3.16-rc1 in 2014. That
added the following conditional which resulted in slices never being
expired.
if (cfs_rq->runtime_expires != cfs_b->runtime_expires) {
/* extend local deadline, drift is bounded above by 2 ticks */
cfs_rq->runtime_expires += TICK_NSEC;
Because this was broken for nearly 5 years, and has recently been fixed
and is now being noticed by many users running kubernetes
(https://github.com/kubernetes/kubernetes/issues/67577) it is my opinion
that the mechanisms around expiring runtime should be removed
altogether.
This allows quota already allocated to per-cpu run-queues to live longer
than the period boundary. This allows threads on runqueues that do not
use much CPU to continue to use their remaining slice over a longer
period of time than cpu.cfs_period_us. However, this helps prevent the
above condition of hitting throttling while also not fully utilizing
your cpu quota.
This theoretically allows a machine to use slightly more than its
allotted quota in some periods. This overflow would be bounded by the
remaining quota left on each per-cpu runqueueu. This is typically no
more than min_cfs_rq_runtime=1ms per cpu. For CPU bound tasks this will
change nothing, as they should theoretically fully utilize all of their
quota in each period. For user-interactive tasks as described above this
provides a much better user/application experience as their cpu
utilization will more closely match the amount they requested when they
hit throttling. This means that cpu limits no longer strictly apply per
period for non-cpu bound applications, but that they are still accurate
over longer timeframes.
This greatly improves performance of high-thread-count, non-cpu bound
applications with low cfs_quota_us allocation on high-core-count
machines. In the case of an artificial testcase (10ms/100ms of quota on
80 CPU machine), this commit resulted in almost 30x performance
improvement, while still maintaining correct cpu quota restrictions.
That testcase is available at https://github.com/indeedeng/fibtest.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Signed-off-by: Dave Chiluk <chiluk+linux@indeed.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: John Hammond <jhammond@indeed.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kyle Anderson <kwa@yelp.com>
Cc: Gabriel Munos <gmunoz@netflix.com>
Cc: Peter Oskolkov <posk@posk.io>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Brendan Gregg <bgregg@netflix.com>
Link: https://lkml.kernel.org/r/1563900266-19734-2-git-send-email-chiluk+linux@indeed.com
2019-07-23 16:44:26 +00:00
|
|
|
static u64 distribute_cfs_runtime(struct cfs_bandwidth *cfs_b, u64 remaining)
|
2011-07-21 16:43:34 +00:00
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq;
|
sched: Fix potential near-infinite distribute_cfs_runtime() loop
distribute_cfs_runtime() intentionally only hands out enough runtime to
bring each cfs_rq to 1 ns of runtime, expecting the cfs_rqs to then take
the runtime they need only once they actually get to run. However, if
they get to run sufficiently quickly, the period timer is still in
distribute_cfs_runtime() and no runtime is available, causing them to
throttle. Then distribute has to handle them again, and this can go on
until distribute has handed out all of the runtime 1ns at a time, which
takes far too long.
Instead allow access to the same runtime that distribute is handing out,
accepting that corner cases with very low quota may be able to spend the
entire cfs_b->runtime during distribute_cfs_runtime, meaning that the
runtime directly handed out by distribute_cfs_runtime was over quota. In
addition, if a cfs_rq does manage to throttle like this, make sure the
existing distribute_cfs_runtime no longer loops over it again.
Signed-off-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140620222120.13814.21652.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-06-20 22:21:20 +00:00
|
|
|
u64 runtime;
|
|
|
|
u64 starting_runtime = remaining;
|
2011-07-21 16:43:34 +00:00
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(cfs_rq, &cfs_b->throttled_cfs_rq,
|
|
|
|
throttled_list) {
|
|
|
|
struct rq *rq = rq_of(cfs_rq);
|
2016-10-04 14:04:35 +00:00
|
|
|
struct rq_flags rf;
|
2011-07-21 16:43:34 +00:00
|
|
|
|
2019-01-07 12:52:31 +00:00
|
|
|
rq_lock_irqsave(rq, &rf);
|
2011-07-21 16:43:34 +00:00
|
|
|
if (!cfs_rq_throttled(cfs_rq))
|
|
|
|
goto next;
|
|
|
|
|
2019-08-26 12:16:33 +00:00
|
|
|
/* By the above check, this should never be true */
|
|
|
|
SCHED_WARN_ON(cfs_rq->runtime_remaining > 0);
|
|
|
|
|
2011-07-21 16:43:34 +00:00
|
|
|
runtime = -cfs_rq->runtime_remaining + 1;
|
|
|
|
if (runtime > remaining)
|
|
|
|
runtime = remaining;
|
|
|
|
remaining -= runtime;
|
|
|
|
|
|
|
|
cfs_rq->runtime_remaining += runtime;
|
|
|
|
|
|
|
|
/* we check whether we're throttled above */
|
|
|
|
if (cfs_rq->runtime_remaining > 0)
|
|
|
|
unthrottle_cfs_rq(cfs_rq);
|
|
|
|
|
|
|
|
next:
|
2019-01-07 12:52:31 +00:00
|
|
|
rq_unlock_irqrestore(rq, &rf);
|
2011-07-21 16:43:34 +00:00
|
|
|
|
|
|
|
if (!remaining)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
sched: Fix potential near-infinite distribute_cfs_runtime() loop
distribute_cfs_runtime() intentionally only hands out enough runtime to
bring each cfs_rq to 1 ns of runtime, expecting the cfs_rqs to then take
the runtime they need only once they actually get to run. However, if
they get to run sufficiently quickly, the period timer is still in
distribute_cfs_runtime() and no runtime is available, causing them to
throttle. Then distribute has to handle them again, and this can go on
until distribute has handed out all of the runtime 1ns at a time, which
takes far too long.
Instead allow access to the same runtime that distribute is handing out,
accepting that corner cases with very low quota may be able to spend the
entire cfs_b->runtime during distribute_cfs_runtime, meaning that the
runtime directly handed out by distribute_cfs_runtime was over quota. In
addition, if a cfs_rq does manage to throttle like this, make sure the
existing distribute_cfs_runtime no longer loops over it again.
Signed-off-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140620222120.13814.21652.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-06-20 22:21:20 +00:00
|
|
|
return starting_runtime - remaining;
|
2011-07-21 16:43:34 +00:00
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:31 +00:00
|
|
|
/*
|
|
|
|
* Responsible for refilling a task_group's bandwidth and unthrottling its
|
|
|
|
* cfs_rqs as appropriate. If there has been no activity within the last
|
|
|
|
* period the timer is deactivated until scheduling resumes; cfs_b->idle is
|
|
|
|
* used to track this state.
|
|
|
|
*/
|
2019-01-07 12:52:31 +00:00
|
|
|
static int do_sched_cfs_period_timer(struct cfs_bandwidth *cfs_b, int overrun, unsigned long flags)
|
2011-07-21 16:43:31 +00:00
|
|
|
{
|
sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
It has been observed, that highly-threaded, non-cpu-bound applications
running under cpu.cfs_quota_us constraints can hit a high percentage of
periods throttled while simultaneously not consuming the allocated
amount of quota. This use case is typical of user-interactive non-cpu
bound applications, such as those running in kubernetes or mesos when
run on multiple cpu cores.
This has been root caused to cpu-local run queue being allocated per cpu
bandwidth slices, and then not fully using that slice within the period.
At which point the slice and quota expires. This expiration of unused
slice results in applications not being able to utilize the quota for
which they are allocated.
The non-expiration of per-cpu slices was recently fixed by
'commit 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift
condition")'. Prior to that it appears that this had been broken since
at least 'commit 51f2176d74ac ("sched/fair: Fix unlocked reads of some
cfs_b->quota/period")' which was introduced in v3.16-rc1 in 2014. That
added the following conditional which resulted in slices never being
expired.
if (cfs_rq->runtime_expires != cfs_b->runtime_expires) {
/* extend local deadline, drift is bounded above by 2 ticks */
cfs_rq->runtime_expires += TICK_NSEC;
Because this was broken for nearly 5 years, and has recently been fixed
and is now being noticed by many users running kubernetes
(https://github.com/kubernetes/kubernetes/issues/67577) it is my opinion
that the mechanisms around expiring runtime should be removed
altogether.
This allows quota already allocated to per-cpu run-queues to live longer
than the period boundary. This allows threads on runqueues that do not
use much CPU to continue to use their remaining slice over a longer
period of time than cpu.cfs_period_us. However, this helps prevent the
above condition of hitting throttling while also not fully utilizing
your cpu quota.
This theoretically allows a machine to use slightly more than its
allotted quota in some periods. This overflow would be bounded by the
remaining quota left on each per-cpu runqueueu. This is typically no
more than min_cfs_rq_runtime=1ms per cpu. For CPU bound tasks this will
change nothing, as they should theoretically fully utilize all of their
quota in each period. For user-interactive tasks as described above this
provides a much better user/application experience as their cpu
utilization will more closely match the amount they requested when they
hit throttling. This means that cpu limits no longer strictly apply per
period for non-cpu bound applications, but that they are still accurate
over longer timeframes.
This greatly improves performance of high-thread-count, non-cpu bound
applications with low cfs_quota_us allocation on high-core-count
machines. In the case of an artificial testcase (10ms/100ms of quota on
80 CPU machine), this commit resulted in almost 30x performance
improvement, while still maintaining correct cpu quota restrictions.
That testcase is available at https://github.com/indeedeng/fibtest.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Signed-off-by: Dave Chiluk <chiluk+linux@indeed.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: John Hammond <jhammond@indeed.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kyle Anderson <kwa@yelp.com>
Cc: Gabriel Munos <gmunoz@netflix.com>
Cc: Peter Oskolkov <posk@posk.io>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Brendan Gregg <bgregg@netflix.com>
Link: https://lkml.kernel.org/r/1563900266-19734-2-git-send-email-chiluk+linux@indeed.com
2019-07-23 16:44:26 +00:00
|
|
|
u64 runtime;
|
2014-05-19 22:49:45 +00:00
|
|
|
int throttled;
|
2011-07-21 16:43:31 +00:00
|
|
|
|
|
|
|
/* no need to continue the timer with no bandwidth constraint */
|
|
|
|
if (cfs_b->quota == RUNTIME_INF)
|
2014-05-19 22:49:45 +00:00
|
|
|
goto out_deactivate;
|
2011-07-21 16:43:31 +00:00
|
|
|
|
2011-07-21 16:43:34 +00:00
|
|
|
throttled = !list_empty(&cfs_b->throttled_cfs_rq);
|
2011-07-21 16:43:40 +00:00
|
|
|
cfs_b->nr_periods += overrun;
|
2011-07-21 16:43:34 +00:00
|
|
|
|
2014-05-19 22:49:45 +00:00
|
|
|
/*
|
|
|
|
* idle depends on !throttled (for the case of a large deficit), and if
|
|
|
|
* we're going inactive then everything else can be deferred
|
|
|
|
*/
|
|
|
|
if (cfs_b->idle && !throttled)
|
|
|
|
goto out_deactivate;
|
2011-07-21 16:43:32 +00:00
|
|
|
|
|
|
|
__refill_cfs_bandwidth_runtime(cfs_b);
|
|
|
|
|
2011-07-21 16:43:34 +00:00
|
|
|
if (!throttled) {
|
|
|
|
/* mark as potentially idle for the upcoming period */
|
|
|
|
cfs_b->idle = 1;
|
2014-05-19 22:49:45 +00:00
|
|
|
return 0;
|
2011-07-21 16:43:34 +00:00
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:40 +00:00
|
|
|
/* account preceding periods in which throttling occurred */
|
|
|
|
cfs_b->nr_throttled += overrun;
|
|
|
|
|
2011-07-21 16:43:34 +00:00
|
|
|
/*
|
sched: Fix potential near-infinite distribute_cfs_runtime() loop
distribute_cfs_runtime() intentionally only hands out enough runtime to
bring each cfs_rq to 1 ns of runtime, expecting the cfs_rqs to then take
the runtime they need only once they actually get to run. However, if
they get to run sufficiently quickly, the period timer is still in
distribute_cfs_runtime() and no runtime is available, causing them to
throttle. Then distribute has to handle them again, and this can go on
until distribute has handed out all of the runtime 1ns at a time, which
takes far too long.
Instead allow access to the same runtime that distribute is handing out,
accepting that corner cases with very low quota may be able to spend the
entire cfs_b->runtime during distribute_cfs_runtime, meaning that the
runtime directly handed out by distribute_cfs_runtime was over quota. In
addition, if a cfs_rq does manage to throttle like this, make sure the
existing distribute_cfs_runtime no longer loops over it again.
Signed-off-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140620222120.13814.21652.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-06-20 22:21:20 +00:00
|
|
|
* This check is repeated as we are holding onto the new bandwidth while
|
|
|
|
* we unthrottle. This can potentially race with an unthrottled group
|
|
|
|
* trying to acquire new bandwidth from the global pool. This can result
|
|
|
|
* in us over-using our runtime if it is all used during this loop, but
|
|
|
|
* only by limited amounts in that extreme case.
|
2011-07-21 16:43:34 +00:00
|
|
|
*/
|
sched/fair: Fix throttle_list starvation with low CFS quota
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve. Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list. The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
Signed-off-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-10-08 14:36:40 +00:00
|
|
|
while (throttled && cfs_b->runtime > 0 && !cfs_b->distribute_running) {
|
sched: Fix potential near-infinite distribute_cfs_runtime() loop
distribute_cfs_runtime() intentionally only hands out enough runtime to
bring each cfs_rq to 1 ns of runtime, expecting the cfs_rqs to then take
the runtime they need only once they actually get to run. However, if
they get to run sufficiently quickly, the period timer is still in
distribute_cfs_runtime() and no runtime is available, causing them to
throttle. Then distribute has to handle them again, and this can go on
until distribute has handed out all of the runtime 1ns at a time, which
takes far too long.
Instead allow access to the same runtime that distribute is handing out,
accepting that corner cases with very low quota may be able to spend the
entire cfs_b->runtime during distribute_cfs_runtime, meaning that the
runtime directly handed out by distribute_cfs_runtime was over quota. In
addition, if a cfs_rq does manage to throttle like this, make sure the
existing distribute_cfs_runtime no longer loops over it again.
Signed-off-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140620222120.13814.21652.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-06-20 22:21:20 +00:00
|
|
|
runtime = cfs_b->runtime;
|
sched/fair: Fix throttle_list starvation with low CFS quota
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve. Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list. The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
Signed-off-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-10-08 14:36:40 +00:00
|
|
|
cfs_b->distribute_running = 1;
|
2019-01-07 12:52:31 +00:00
|
|
|
raw_spin_unlock_irqrestore(&cfs_b->lock, flags);
|
2011-07-21 16:43:34 +00:00
|
|
|
/* we can't nest cfs_b->lock while distributing bandwidth */
|
sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
It has been observed, that highly-threaded, non-cpu-bound applications
running under cpu.cfs_quota_us constraints can hit a high percentage of
periods throttled while simultaneously not consuming the allocated
amount of quota. This use case is typical of user-interactive non-cpu
bound applications, such as those running in kubernetes or mesos when
run on multiple cpu cores.
This has been root caused to cpu-local run queue being allocated per cpu
bandwidth slices, and then not fully using that slice within the period.
At which point the slice and quota expires. This expiration of unused
slice results in applications not being able to utilize the quota for
which they are allocated.
The non-expiration of per-cpu slices was recently fixed by
'commit 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift
condition")'. Prior to that it appears that this had been broken since
at least 'commit 51f2176d74ac ("sched/fair: Fix unlocked reads of some
cfs_b->quota/period")' which was introduced in v3.16-rc1 in 2014. That
added the following conditional which resulted in slices never being
expired.
if (cfs_rq->runtime_expires != cfs_b->runtime_expires) {
/* extend local deadline, drift is bounded above by 2 ticks */
cfs_rq->runtime_expires += TICK_NSEC;
Because this was broken for nearly 5 years, and has recently been fixed
and is now being noticed by many users running kubernetes
(https://github.com/kubernetes/kubernetes/issues/67577) it is my opinion
that the mechanisms around expiring runtime should be removed
altogether.
This allows quota already allocated to per-cpu run-queues to live longer
than the period boundary. This allows threads on runqueues that do not
use much CPU to continue to use their remaining slice over a longer
period of time than cpu.cfs_period_us. However, this helps prevent the
above condition of hitting throttling while also not fully utilizing
your cpu quota.
This theoretically allows a machine to use slightly more than its
allotted quota in some periods. This overflow would be bounded by the
remaining quota left on each per-cpu runqueueu. This is typically no
more than min_cfs_rq_runtime=1ms per cpu. For CPU bound tasks this will
change nothing, as they should theoretically fully utilize all of their
quota in each period. For user-interactive tasks as described above this
provides a much better user/application experience as their cpu
utilization will more closely match the amount they requested when they
hit throttling. This means that cpu limits no longer strictly apply per
period for non-cpu bound applications, but that they are still accurate
over longer timeframes.
This greatly improves performance of high-thread-count, non-cpu bound
applications with low cfs_quota_us allocation on high-core-count
machines. In the case of an artificial testcase (10ms/100ms of quota on
80 CPU machine), this commit resulted in almost 30x performance
improvement, while still maintaining correct cpu quota restrictions.
That testcase is available at https://github.com/indeedeng/fibtest.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Signed-off-by: Dave Chiluk <chiluk+linux@indeed.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: John Hammond <jhammond@indeed.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kyle Anderson <kwa@yelp.com>
Cc: Gabriel Munos <gmunoz@netflix.com>
Cc: Peter Oskolkov <posk@posk.io>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Brendan Gregg <bgregg@netflix.com>
Link: https://lkml.kernel.org/r/1563900266-19734-2-git-send-email-chiluk+linux@indeed.com
2019-07-23 16:44:26 +00:00
|
|
|
runtime = distribute_cfs_runtime(cfs_b, runtime);
|
2019-01-07 12:52:31 +00:00
|
|
|
raw_spin_lock_irqsave(&cfs_b->lock, flags);
|
2011-07-21 16:43:34 +00:00
|
|
|
|
sched/fair: Fix throttle_list starvation with low CFS quota
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve. Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list. The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
Signed-off-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-10-08 14:36:40 +00:00
|
|
|
cfs_b->distribute_running = 0;
|
2011-07-21 16:43:34 +00:00
|
|
|
throttled = !list_empty(&cfs_b->throttled_cfs_rq);
|
sched: Fix potential near-infinite distribute_cfs_runtime() loop
distribute_cfs_runtime() intentionally only hands out enough runtime to
bring each cfs_rq to 1 ns of runtime, expecting the cfs_rqs to then take
the runtime they need only once they actually get to run. However, if
they get to run sufficiently quickly, the period timer is still in
distribute_cfs_runtime() and no runtime is available, causing them to
throttle. Then distribute has to handle them again, and this can go on
until distribute has handed out all of the runtime 1ns at a time, which
takes far too long.
Instead allow access to the same runtime that distribute is handing out,
accepting that corner cases with very low quota may be able to spend the
entire cfs_b->runtime during distribute_cfs_runtime, meaning that the
runtime directly handed out by distribute_cfs_runtime was over quota. In
addition, if a cfs_rq does manage to throttle like this, make sure the
existing distribute_cfs_runtime no longer loops over it again.
Signed-off-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140620222120.13814.21652.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-06-20 22:21:20 +00:00
|
|
|
|
2018-11-05 14:54:00 +00:00
|
|
|
lsub_positive(&cfs_b->runtime, runtime);
|
2011-07-21 16:43:34 +00:00
|
|
|
}
|
2011-07-21 16:43:31 +00:00
|
|
|
|
2011-07-21 16:43:34 +00:00
|
|
|
/*
|
|
|
|
* While we are ensured activity in the period following an
|
|
|
|
* unthrottle, this also covers the case in which the new bandwidth is
|
|
|
|
* insufficient to cover the existing bandwidth deficit. (Forcing the
|
|
|
|
* timer to remain active while there are any throttled entities.)
|
|
|
|
*/
|
|
|
|
cfs_b->idle = 0;
|
2011-07-21 16:43:31 +00:00
|
|
|
|
2014-05-19 22:49:45 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_deactivate:
|
|
|
|
return 1;
|
2011-07-21 16:43:31 +00:00
|
|
|
}
|
2011-07-21 16:43:39 +00:00
|
|
|
|
2011-07-21 16:43:41 +00:00
|
|
|
/* a cfs_rq won't donate quota below this amount */
|
|
|
|
static const u64 min_cfs_rq_runtime = 1 * NSEC_PER_MSEC;
|
|
|
|
/* minimum remaining period time to redistribute slack quota */
|
|
|
|
static const u64 min_bandwidth_expiration = 2 * NSEC_PER_MSEC;
|
|
|
|
/* how long we wait to gather additional slack before distributing */
|
|
|
|
static const u64 cfs_bandwidth_slack_period = 5 * NSEC_PER_MSEC;
|
|
|
|
|
2013-10-16 18:16:17 +00:00
|
|
|
/*
|
|
|
|
* Are we near the end of the current quota period?
|
|
|
|
*
|
|
|
|
* Requires cfs_b->lock for hrtimer_expires_remaining to be safe against the
|
2015-04-14 21:09:05 +00:00
|
|
|
* hrtimer base being cleared by hrtimer_start. In the case of
|
2013-10-16 18:16:17 +00:00
|
|
|
* migrate_hrtimers, base is never cleared, so we are fine.
|
|
|
|
*/
|
2011-07-21 16:43:41 +00:00
|
|
|
static int runtime_refresh_within(struct cfs_bandwidth *cfs_b, u64 min_expire)
|
|
|
|
{
|
|
|
|
struct hrtimer *refresh_timer = &cfs_b->period_timer;
|
|
|
|
u64 remaining;
|
|
|
|
|
|
|
|
/* if the call-back is running a quota refresh is already occurring */
|
|
|
|
if (hrtimer_callback_running(refresh_timer))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
/* is a quota refresh about to occur? */
|
|
|
|
remaining = ktime_to_ns(hrtimer_expires_remaining(refresh_timer));
|
|
|
|
if (remaining < min_expire)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void start_cfs_slack_bandwidth(struct cfs_bandwidth *cfs_b)
|
|
|
|
{
|
|
|
|
u64 min_left = cfs_bandwidth_slack_period + min_bandwidth_expiration;
|
|
|
|
|
|
|
|
/* if there's a quota refresh soon don't bother with slack */
|
|
|
|
if (runtime_refresh_within(cfs_b, min_left))
|
|
|
|
return;
|
|
|
|
|
2019-06-06 17:21:01 +00:00
|
|
|
/* don't push forwards an existing deferred unthrottle */
|
|
|
|
if (cfs_b->slack_started)
|
|
|
|
return;
|
|
|
|
cfs_b->slack_started = true;
|
|
|
|
|
sched,perf: Fix periodic timers
In the below two commits (see Fixes) we have periodic timers that can
stop themselves when they're no longer required, but need to be
(re)-started when their idle condition changes.
Further complications is that we want the timer handler to always do
the forward such that it will always correctly deal with the overruns,
and we do not want to race such that the handler has already decided
to stop, but the (external) restart sees the timer still active and we
end up with a 'lost' timer.
The problem with the current code is that the re-start can come before
the callback does the forward, at which point the forward from the
callback will WARN about forwarding an enqueued timer.
Now, conceptually its easy to detect if you're before or after the fwd
by comparing the expiration time against the current time. Of course,
that's expensive (and racy) because we don't have the current time.
Alternatively one could cache this state inside the timer, but then
everybody pays the overhead of maintaining this extra state, and that
is undesired.
The only other option that I could see is the external timer_active
variable, which I tried to kill before. I would love a nicer interface
for this seemingly simple 'problem' but alas.
Fixes: 272325c4821f ("perf: Fix mux_interval hrtimer wreckage")
Fixes: 77a4d1a1b9a1 ("sched: Cleanup bandwidth timers")
Cc: pjt@google.com
Cc: tglx@linutronix.de
Cc: klamm@yandex-team.ru
Cc: mingo@kernel.org
Cc: bsegall@google.com
Cc: hpa@zytor.com
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20150514102311.GX21418@twins.programming.kicks-ass.net
2015-05-14 10:23:11 +00:00
|
|
|
hrtimer_start(&cfs_b->slack_timer,
|
|
|
|
ns_to_ktime(cfs_bandwidth_slack_period),
|
|
|
|
HRTIMER_MODE_REL);
|
2011-07-21 16:43:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* we know any runtime found here is valid as update_curr() precedes return */
|
|
|
|
static void __return_cfs_rq_runtime(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
struct cfs_bandwidth *cfs_b = tg_cfs_bandwidth(cfs_rq->tg);
|
|
|
|
s64 slack_runtime = cfs_rq->runtime_remaining - min_cfs_rq_runtime;
|
|
|
|
|
|
|
|
if (slack_runtime <= 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
raw_spin_lock(&cfs_b->lock);
|
sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
It has been observed, that highly-threaded, non-cpu-bound applications
running under cpu.cfs_quota_us constraints can hit a high percentage of
periods throttled while simultaneously not consuming the allocated
amount of quota. This use case is typical of user-interactive non-cpu
bound applications, such as those running in kubernetes or mesos when
run on multiple cpu cores.
This has been root caused to cpu-local run queue being allocated per cpu
bandwidth slices, and then not fully using that slice within the period.
At which point the slice and quota expires. This expiration of unused
slice results in applications not being able to utilize the quota for
which they are allocated.
The non-expiration of per-cpu slices was recently fixed by
'commit 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift
condition")'. Prior to that it appears that this had been broken since
at least 'commit 51f2176d74ac ("sched/fair: Fix unlocked reads of some
cfs_b->quota/period")' which was introduced in v3.16-rc1 in 2014. That
added the following conditional which resulted in slices never being
expired.
if (cfs_rq->runtime_expires != cfs_b->runtime_expires) {
/* extend local deadline, drift is bounded above by 2 ticks */
cfs_rq->runtime_expires += TICK_NSEC;
Because this was broken for nearly 5 years, and has recently been fixed
and is now being noticed by many users running kubernetes
(https://github.com/kubernetes/kubernetes/issues/67577) it is my opinion
that the mechanisms around expiring runtime should be removed
altogether.
This allows quota already allocated to per-cpu run-queues to live longer
than the period boundary. This allows threads on runqueues that do not
use much CPU to continue to use their remaining slice over a longer
period of time than cpu.cfs_period_us. However, this helps prevent the
above condition of hitting throttling while also not fully utilizing
your cpu quota.
This theoretically allows a machine to use slightly more than its
allotted quota in some periods. This overflow would be bounded by the
remaining quota left on each per-cpu runqueueu. This is typically no
more than min_cfs_rq_runtime=1ms per cpu. For CPU bound tasks this will
change nothing, as they should theoretically fully utilize all of their
quota in each period. For user-interactive tasks as described above this
provides a much better user/application experience as their cpu
utilization will more closely match the amount they requested when they
hit throttling. This means that cpu limits no longer strictly apply per
period for non-cpu bound applications, but that they are still accurate
over longer timeframes.
This greatly improves performance of high-thread-count, non-cpu bound
applications with low cfs_quota_us allocation on high-core-count
machines. In the case of an artificial testcase (10ms/100ms of quota on
80 CPU machine), this commit resulted in almost 30x performance
improvement, while still maintaining correct cpu quota restrictions.
That testcase is available at https://github.com/indeedeng/fibtest.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Signed-off-by: Dave Chiluk <chiluk+linux@indeed.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: John Hammond <jhammond@indeed.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kyle Anderson <kwa@yelp.com>
Cc: Gabriel Munos <gmunoz@netflix.com>
Cc: Peter Oskolkov <posk@posk.io>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Brendan Gregg <bgregg@netflix.com>
Link: https://lkml.kernel.org/r/1563900266-19734-2-git-send-email-chiluk+linux@indeed.com
2019-07-23 16:44:26 +00:00
|
|
|
if (cfs_b->quota != RUNTIME_INF) {
|
2011-07-21 16:43:41 +00:00
|
|
|
cfs_b->runtime += slack_runtime;
|
|
|
|
|
|
|
|
/* we are under rq->lock, defer unthrottling using a timer */
|
|
|
|
if (cfs_b->runtime > sched_cfs_bandwidth_slice() &&
|
|
|
|
!list_empty(&cfs_b->throttled_cfs_rq))
|
|
|
|
start_cfs_slack_bandwidth(cfs_b);
|
|
|
|
}
|
|
|
|
raw_spin_unlock(&cfs_b->lock);
|
|
|
|
|
|
|
|
/* even if it's not valid for return we don't want to try again */
|
|
|
|
cfs_rq->runtime_remaining -= slack_runtime;
|
|
|
|
}
|
|
|
|
|
|
|
|
static __always_inline void return_cfs_rq_runtime(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
2011-11-08 04:26:33 +00:00
|
|
|
if (!cfs_bandwidth_used())
|
|
|
|
return;
|
|
|
|
|
2011-11-08 04:26:34 +00:00
|
|
|
if (!cfs_rq->runtime_enabled || cfs_rq->nr_running)
|
2011-07-21 16:43:41 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
__return_cfs_rq_runtime(cfs_rq);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is done with a timer (instead of inline with bandwidth return) since
|
|
|
|
* it's necessary to juggle rq->locks to unthrottle their respective cfs_rqs.
|
|
|
|
*/
|
|
|
|
static void do_sched_cfs_slack_timer(struct cfs_bandwidth *cfs_b)
|
|
|
|
{
|
|
|
|
u64 runtime = 0, slice = sched_cfs_bandwidth_slice();
|
2019-01-07 12:52:31 +00:00
|
|
|
unsigned long flags;
|
2011-07-21 16:43:41 +00:00
|
|
|
|
|
|
|
/* confirm we're still not at a refresh boundary */
|
2019-01-07 12:52:31 +00:00
|
|
|
raw_spin_lock_irqsave(&cfs_b->lock, flags);
|
2019-06-06 17:21:01 +00:00
|
|
|
cfs_b->slack_started = false;
|
sched/fair: Fix throttle_list starvation with low CFS quota
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve. Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list. The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
Signed-off-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-10-08 14:36:40 +00:00
|
|
|
if (cfs_b->distribute_running) {
|
2019-01-07 12:52:31 +00:00
|
|
|
raw_spin_unlock_irqrestore(&cfs_b->lock, flags);
|
sched/fair: Fix throttle_list starvation with low CFS quota
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve. Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list. The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
Signed-off-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-10-08 14:36:40 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-10-16 18:16:17 +00:00
|
|
|
if (runtime_refresh_within(cfs_b, min_bandwidth_expiration)) {
|
2019-01-07 12:52:31 +00:00
|
|
|
raw_spin_unlock_irqrestore(&cfs_b->lock, flags);
|
2011-07-21 16:43:41 +00:00
|
|
|
return;
|
2013-10-16 18:16:17 +00:00
|
|
|
}
|
2011-07-21 16:43:41 +00:00
|
|
|
|
sched: Fix potential near-infinite distribute_cfs_runtime() loop
distribute_cfs_runtime() intentionally only hands out enough runtime to
bring each cfs_rq to 1 ns of runtime, expecting the cfs_rqs to then take
the runtime they need only once they actually get to run. However, if
they get to run sufficiently quickly, the period timer is still in
distribute_cfs_runtime() and no runtime is available, causing them to
throttle. Then distribute has to handle them again, and this can go on
until distribute has handed out all of the runtime 1ns at a time, which
takes far too long.
Instead allow access to the same runtime that distribute is handing out,
accepting that corner cases with very low quota may be able to spend the
entire cfs_b->runtime during distribute_cfs_runtime, meaning that the
runtime directly handed out by distribute_cfs_runtime was over quota. In
addition, if a cfs_rq does manage to throttle like this, make sure the
existing distribute_cfs_runtime no longer loops over it again.
Signed-off-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140620222120.13814.21652.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-06-20 22:21:20 +00:00
|
|
|
if (cfs_b->quota != RUNTIME_INF && cfs_b->runtime > slice)
|
2011-07-21 16:43:41 +00:00
|
|
|
runtime = cfs_b->runtime;
|
sched: Fix potential near-infinite distribute_cfs_runtime() loop
distribute_cfs_runtime() intentionally only hands out enough runtime to
bring each cfs_rq to 1 ns of runtime, expecting the cfs_rqs to then take
the runtime they need only once they actually get to run. However, if
they get to run sufficiently quickly, the period timer is still in
distribute_cfs_runtime() and no runtime is available, causing them to
throttle. Then distribute has to handle them again, and this can go on
until distribute has handed out all of the runtime 1ns at a time, which
takes far too long.
Instead allow access to the same runtime that distribute is handing out,
accepting that corner cases with very low quota may be able to spend the
entire cfs_b->runtime during distribute_cfs_runtime, meaning that the
runtime directly handed out by distribute_cfs_runtime was over quota. In
addition, if a cfs_rq does manage to throttle like this, make sure the
existing distribute_cfs_runtime no longer loops over it again.
Signed-off-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20140620222120.13814.21652.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-06-20 22:21:20 +00:00
|
|
|
|
sched/fair: Fix throttle_list starvation with low CFS quota
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve. Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list. The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
Signed-off-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-10-08 14:36:40 +00:00
|
|
|
if (runtime)
|
|
|
|
cfs_b->distribute_running = 1;
|
|
|
|
|
2019-01-07 12:52:31 +00:00
|
|
|
raw_spin_unlock_irqrestore(&cfs_b->lock, flags);
|
2011-07-21 16:43:41 +00:00
|
|
|
|
|
|
|
if (!runtime)
|
|
|
|
return;
|
|
|
|
|
sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
It has been observed, that highly-threaded, non-cpu-bound applications
running under cpu.cfs_quota_us constraints can hit a high percentage of
periods throttled while simultaneously not consuming the allocated
amount of quota. This use case is typical of user-interactive non-cpu
bound applications, such as those running in kubernetes or mesos when
run on multiple cpu cores.
This has been root caused to cpu-local run queue being allocated per cpu
bandwidth slices, and then not fully using that slice within the period.
At which point the slice and quota expires. This expiration of unused
slice results in applications not being able to utilize the quota for
which they are allocated.
The non-expiration of per-cpu slices was recently fixed by
'commit 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift
condition")'. Prior to that it appears that this had been broken since
at least 'commit 51f2176d74ac ("sched/fair: Fix unlocked reads of some
cfs_b->quota/period")' which was introduced in v3.16-rc1 in 2014. That
added the following conditional which resulted in slices never being
expired.
if (cfs_rq->runtime_expires != cfs_b->runtime_expires) {
/* extend local deadline, drift is bounded above by 2 ticks */
cfs_rq->runtime_expires += TICK_NSEC;
Because this was broken for nearly 5 years, and has recently been fixed
and is now being noticed by many users running kubernetes
(https://github.com/kubernetes/kubernetes/issues/67577) it is my opinion
that the mechanisms around expiring runtime should be removed
altogether.
This allows quota already allocated to per-cpu run-queues to live longer
than the period boundary. This allows threads on runqueues that do not
use much CPU to continue to use their remaining slice over a longer
period of time than cpu.cfs_period_us. However, this helps prevent the
above condition of hitting throttling while also not fully utilizing
your cpu quota.
This theoretically allows a machine to use slightly more than its
allotted quota in some periods. This overflow would be bounded by the
remaining quota left on each per-cpu runqueueu. This is typically no
more than min_cfs_rq_runtime=1ms per cpu. For CPU bound tasks this will
change nothing, as they should theoretically fully utilize all of their
quota in each period. For user-interactive tasks as described above this
provides a much better user/application experience as their cpu
utilization will more closely match the amount they requested when they
hit throttling. This means that cpu limits no longer strictly apply per
period for non-cpu bound applications, but that they are still accurate
over longer timeframes.
This greatly improves performance of high-thread-count, non-cpu bound
applications with low cfs_quota_us allocation on high-core-count
machines. In the case of an artificial testcase (10ms/100ms of quota on
80 CPU machine), this commit resulted in almost 30x performance
improvement, while still maintaining correct cpu quota restrictions.
That testcase is available at https://github.com/indeedeng/fibtest.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Signed-off-by: Dave Chiluk <chiluk+linux@indeed.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: John Hammond <jhammond@indeed.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kyle Anderson <kwa@yelp.com>
Cc: Gabriel Munos <gmunoz@netflix.com>
Cc: Peter Oskolkov <posk@posk.io>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Brendan Gregg <bgregg@netflix.com>
Link: https://lkml.kernel.org/r/1563900266-19734-2-git-send-email-chiluk+linux@indeed.com
2019-07-23 16:44:26 +00:00
|
|
|
runtime = distribute_cfs_runtime(cfs_b, runtime);
|
2011-07-21 16:43:41 +00:00
|
|
|
|
2019-01-07 12:52:31 +00:00
|
|
|
raw_spin_lock_irqsave(&cfs_b->lock, flags);
|
sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
It has been observed, that highly-threaded, non-cpu-bound applications
running under cpu.cfs_quota_us constraints can hit a high percentage of
periods throttled while simultaneously not consuming the allocated
amount of quota. This use case is typical of user-interactive non-cpu
bound applications, such as those running in kubernetes or mesos when
run on multiple cpu cores.
This has been root caused to cpu-local run queue being allocated per cpu
bandwidth slices, and then not fully using that slice within the period.
At which point the slice and quota expires. This expiration of unused
slice results in applications not being able to utilize the quota for
which they are allocated.
The non-expiration of per-cpu slices was recently fixed by
'commit 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift
condition")'. Prior to that it appears that this had been broken since
at least 'commit 51f2176d74ac ("sched/fair: Fix unlocked reads of some
cfs_b->quota/period")' which was introduced in v3.16-rc1 in 2014. That
added the following conditional which resulted in slices never being
expired.
if (cfs_rq->runtime_expires != cfs_b->runtime_expires) {
/* extend local deadline, drift is bounded above by 2 ticks */
cfs_rq->runtime_expires += TICK_NSEC;
Because this was broken for nearly 5 years, and has recently been fixed
and is now being noticed by many users running kubernetes
(https://github.com/kubernetes/kubernetes/issues/67577) it is my opinion
that the mechanisms around expiring runtime should be removed
altogether.
This allows quota already allocated to per-cpu run-queues to live longer
than the period boundary. This allows threads on runqueues that do not
use much CPU to continue to use their remaining slice over a longer
period of time than cpu.cfs_period_us. However, this helps prevent the
above condition of hitting throttling while also not fully utilizing
your cpu quota.
This theoretically allows a machine to use slightly more than its
allotted quota in some periods. This overflow would be bounded by the
remaining quota left on each per-cpu runqueueu. This is typically no
more than min_cfs_rq_runtime=1ms per cpu. For CPU bound tasks this will
change nothing, as they should theoretically fully utilize all of their
quota in each period. For user-interactive tasks as described above this
provides a much better user/application experience as their cpu
utilization will more closely match the amount they requested when they
hit throttling. This means that cpu limits no longer strictly apply per
period for non-cpu bound applications, but that they are still accurate
over longer timeframes.
This greatly improves performance of high-thread-count, non-cpu bound
applications with low cfs_quota_us allocation on high-core-count
machines. In the case of an artificial testcase (10ms/100ms of quota on
80 CPU machine), this commit resulted in almost 30x performance
improvement, while still maintaining correct cpu quota restrictions.
That testcase is available at https://github.com/indeedeng/fibtest.
Fixes: 512ac999d275 ("sched/fair: Fix bandwidth timer clock drift condition")
Signed-off-by: Dave Chiluk <chiluk+linux@indeed.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: John Hammond <jhammond@indeed.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kyle Anderson <kwa@yelp.com>
Cc: Gabriel Munos <gmunoz@netflix.com>
Cc: Peter Oskolkov <posk@posk.io>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Brendan Gregg <bgregg@netflix.com>
Link: https://lkml.kernel.org/r/1563900266-19734-2-git-send-email-chiluk+linux@indeed.com
2019-07-23 16:44:26 +00:00
|
|
|
lsub_positive(&cfs_b->runtime, runtime);
|
sched/fair: Fix throttle_list starvation with low CFS quota
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve. Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list. The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
Signed-off-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-10-08 14:36:40 +00:00
|
|
|
cfs_b->distribute_running = 0;
|
2019-01-07 12:52:31 +00:00
|
|
|
raw_spin_unlock_irqrestore(&cfs_b->lock, flags);
|
2011-07-21 16:43:41 +00:00
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:39 +00:00
|
|
|
/*
|
|
|
|
* When a group wakes up we want to make sure that its quota is not already
|
|
|
|
* expired/exceeded, otherwise it may be allowed to steal additional ticks of
|
|
|
|
* runtime as update_curr() throttling can not not trigger until it's on-rq.
|
|
|
|
*/
|
|
|
|
static void check_enqueue_throttle(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
2011-11-08 04:26:33 +00:00
|
|
|
if (!cfs_bandwidth_used())
|
|
|
|
return;
|
|
|
|
|
2011-07-21 16:43:39 +00:00
|
|
|
/* an active group must be handled by the update_curr()->put() path */
|
|
|
|
if (!cfs_rq->runtime_enabled || cfs_rq->curr)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* ensure the group is not already throttled */
|
|
|
|
if (cfs_rq_throttled(cfs_rq))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* update runtime allocation */
|
|
|
|
account_cfs_rq_runtime(cfs_rq, 0);
|
|
|
|
if (cfs_rq->runtime_remaining <= 0)
|
|
|
|
throttle_cfs_rq(cfs_rq);
|
|
|
|
}
|
|
|
|
|
2016-06-22 13:14:26 +00:00
|
|
|
static void sync_throttle(struct task_group *tg, int cpu)
|
|
|
|
{
|
|
|
|
struct cfs_rq *pcfs_rq, *cfs_rq;
|
|
|
|
|
|
|
|
if (!cfs_bandwidth_used())
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!tg->parent)
|
|
|
|
return;
|
|
|
|
|
|
|
|
cfs_rq = tg->cfs_rq[cpu];
|
|
|
|
pcfs_rq = tg->parent->cfs_rq[cpu];
|
|
|
|
|
|
|
|
cfs_rq->throttle_count = pcfs_rq->throttle_count;
|
2016-07-09 07:54:22 +00:00
|
|
|
cfs_rq->throttled_clock_task = rq_clock_task(cpu_rq(cpu));
|
2016-06-22 13:14:26 +00:00
|
|
|
}
|
|
|
|
|
2011-07-21 16:43:39 +00:00
|
|
|
/* conditionally throttle active cfs_rq's from put_prev_entity() */
|
2012-02-11 05:05:00 +00:00
|
|
|
static bool check_cfs_rq_runtime(struct cfs_rq *cfs_rq)
|
2011-07-21 16:43:39 +00:00
|
|
|
{
|
2011-11-08 04:26:33 +00:00
|
|
|
if (!cfs_bandwidth_used())
|
2012-02-11 05:05:00 +00:00
|
|
|
return false;
|
2011-11-08 04:26:33 +00:00
|
|
|
|
2011-07-21 16:43:39 +00:00
|
|
|
if (likely(!cfs_rq->runtime_enabled || cfs_rq->runtime_remaining > 0))
|
2012-02-11 05:05:00 +00:00
|
|
|
return false;
|
2011-07-21 16:43:39 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* it's possible for a throttled entity to be forced into a running
|
|
|
|
* state (e.g. set_curr_task), in this case we're finished.
|
|
|
|
*/
|
|
|
|
if (cfs_rq_throttled(cfs_rq))
|
2012-02-11 05:05:00 +00:00
|
|
|
return true;
|
2011-07-21 16:43:39 +00:00
|
|
|
|
|
|
|
throttle_cfs_rq(cfs_rq);
|
2012-02-11 05:05:00 +00:00
|
|
|
return true;
|
2011-07-21 16:43:39 +00:00
|
|
|
}
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
static enum hrtimer_restart sched_cfs_slack_timer(struct hrtimer *timer)
|
|
|
|
{
|
|
|
|
struct cfs_bandwidth *cfs_b =
|
|
|
|
container_of(timer, struct cfs_bandwidth, slack_timer);
|
sched: Cleanup bandwidth timers
Roman reported a 3 cpu lockup scenario involving __start_cfs_bandwidth().
The more I look at that code the more I'm convinced its crack, that
entire __start_cfs_bandwidth() thing is brain melting, we don't need to
cancel a timer before starting it, *hrtimer_start*() will happily remove
the timer for you if its still enqueued.
Removing that, removes a big part of the problem, no more ugly cancel
loop to get stuck in.
So now, if I understand things right, the entire reason you have this
cfs_b->lock guarded ->timer_active nonsense is to make sure we don't
accidentally lose the timer.
It appears to me that it should be possible to guarantee that same by
unconditionally (re)starting the timer when !queued. Because regardless
what hrtimer::function will return, if we beat it to (re)enqueue the
timer, it doesn't matter.
Now, because hrtimers don't come with any serialization guarantees we
must ensure both handler and (re)start loop serialize their access to
the hrtimer to avoid both trying to forward the timer at the same
time.
Update the rt bandwidth timer to match.
This effectively reverts: 09dc4ab03936 ("sched/fair: Fix
tg_set_cfs_bandwidth() deadlock on rq->lock").
Reported-by: Roman Gushchin <klamm@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Paul Turner <pjt@google.com>
Link: http://lkml.kernel.org/r/20150415095011.804589208@infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-04-15 09:41:57 +00:00
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
do_sched_cfs_slack_timer(cfs_b);
|
|
|
|
|
|
|
|
return HRTIMER_NORESTART;
|
|
|
|
}
|
|
|
|
|
2019-03-19 13:00:05 +00:00
|
|
|
extern const u64 max_cfs_quota_period;
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer)
|
|
|
|
{
|
|
|
|
struct cfs_bandwidth *cfs_b =
|
|
|
|
container_of(timer, struct cfs_bandwidth, period_timer);
|
2019-01-07 12:52:31 +00:00
|
|
|
unsigned long flags;
|
2011-10-25 08:00:11 +00:00
|
|
|
int overrun;
|
|
|
|
int idle = 0;
|
2019-03-19 13:00:05 +00:00
|
|
|
int count = 0;
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2019-01-07 12:52:31 +00:00
|
|
|
raw_spin_lock_irqsave(&cfs_b->lock, flags);
|
2011-10-25 08:00:11 +00:00
|
|
|
for (;;) {
|
sched: Cleanup bandwidth timers
Roman reported a 3 cpu lockup scenario involving __start_cfs_bandwidth().
The more I look at that code the more I'm convinced its crack, that
entire __start_cfs_bandwidth() thing is brain melting, we don't need to
cancel a timer before starting it, *hrtimer_start*() will happily remove
the timer for you if its still enqueued.
Removing that, removes a big part of the problem, no more ugly cancel
loop to get stuck in.
So now, if I understand things right, the entire reason you have this
cfs_b->lock guarded ->timer_active nonsense is to make sure we don't
accidentally lose the timer.
It appears to me that it should be possible to guarantee that same by
unconditionally (re)starting the timer when !queued. Because regardless
what hrtimer::function will return, if we beat it to (re)enqueue the
timer, it doesn't matter.
Now, because hrtimers don't come with any serialization guarantees we
must ensure both handler and (re)start loop serialize their access to
the hrtimer to avoid both trying to forward the timer at the same
time.
Update the rt bandwidth timer to match.
This effectively reverts: 09dc4ab03936 ("sched/fair: Fix
tg_set_cfs_bandwidth() deadlock on rq->lock").
Reported-by: Roman Gushchin <klamm@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Paul Turner <pjt@google.com>
Link: http://lkml.kernel.org/r/20150415095011.804589208@infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-04-15 09:41:57 +00:00
|
|
|
overrun = hrtimer_forward_now(timer, cfs_b->period);
|
2011-10-25 08:00:11 +00:00
|
|
|
if (!overrun)
|
|
|
|
break;
|
|
|
|
|
2019-03-19 13:00:05 +00:00
|
|
|
if (++count > 3) {
|
|
|
|
u64 new, old = ktime_to_ns(cfs_b->period);
|
|
|
|
|
sched/fair: Scale bandwidth quota and period without losing quota/period ratio precision
The quota/period ratio is used to ensure a child task group won't get
more bandwidth than the parent task group, and is calculated as:
normalized_cfs_quota() = [(quota_us << 20) / period_us]
If the quota/period ratio was changed during this scaling due to
precision loss, it will cause inconsistency between parent and child
task groups.
See below example:
A userspace container manager (kubelet) does three operations:
1) Create a parent cgroup, set quota to 1,000us and period to 10,000us.
2) Create a few children cgroups.
3) Set quota to 1,000us and period to 10,000us on a child cgroup.
These operations are expected to succeed. However, if the scaling of
147/128 happens before step 3, quota and period of the parent cgroup
will be changed:
new_quota: 1148437ns, 1148us
new_period: 11484375ns, 11484us
And when step 3 comes in, the ratio of the child cgroup will be
104857, which will be larger than the parent cgroup ratio (104821),
and will fail.
Scaling them by a factor of 2 will fix the problem.
Tested-by: Phil Auld <pauld@redhat.com>
Signed-off-by: Xuewei Zhang <xueweiz@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Phil Auld <pauld@redhat.com>
Cc: Anton Blanchard <anton@ozlabs.org>
Cc: Ben Segall <bsegall@google.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop to avoid hard lockup")
Link: https://lkml.kernel.org/r/20191004001243.140897-1-xueweiz@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-10-04 00:12:43 +00:00
|
|
|
/*
|
|
|
|
* Grow period by a factor of 2 to avoid losing precision.
|
|
|
|
* Precision loss in the quota/period ratio can cause __cfs_schedulable
|
|
|
|
* to fail.
|
|
|
|
*/
|
|
|
|
new = old * 2;
|
|
|
|
if (new < max_cfs_quota_period) {
|
|
|
|
cfs_b->period = ns_to_ktime(new);
|
|
|
|
cfs_b->quota *= 2;
|
|
|
|
|
|
|
|
pr_warn_ratelimited(
|
|
|
|
"cfs_period_timer[cpu%d]: period too short, scaling up (new cfs_period_us = %lld, cfs_quota_us = %lld)\n",
|
|
|
|
smp_processor_id(),
|
|
|
|
div_u64(new, NSEC_PER_USEC),
|
|
|
|
div_u64(cfs_b->quota, NSEC_PER_USEC));
|
|
|
|
} else {
|
|
|
|
pr_warn_ratelimited(
|
|
|
|
"cfs_period_timer[cpu%d]: period too short, but cannot scale up without losing precision (cfs_period_us = %lld, cfs_quota_us = %lld)\n",
|
|
|
|
smp_processor_id(),
|
|
|
|
div_u64(old, NSEC_PER_USEC),
|
|
|
|
div_u64(cfs_b->quota, NSEC_PER_USEC));
|
|
|
|
}
|
2019-03-19 13:00:05 +00:00
|
|
|
|
|
|
|
/* reset count so we don't come right back in here */
|
|
|
|
count = 0;
|
|
|
|
}
|
|
|
|
|
2019-01-07 12:52:31 +00:00
|
|
|
idle = do_sched_cfs_period_timer(cfs_b, overrun, flags);
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
sched,perf: Fix periodic timers
In the below two commits (see Fixes) we have periodic timers that can
stop themselves when they're no longer required, but need to be
(re)-started when their idle condition changes.
Further complications is that we want the timer handler to always do
the forward such that it will always correctly deal with the overruns,
and we do not want to race such that the handler has already decided
to stop, but the (external) restart sees the timer still active and we
end up with a 'lost' timer.
The problem with the current code is that the re-start can come before
the callback does the forward, at which point the forward from the
callback will WARN about forwarding an enqueued timer.
Now, conceptually its easy to detect if you're before or after the fwd
by comparing the expiration time against the current time. Of course,
that's expensive (and racy) because we don't have the current time.
Alternatively one could cache this state inside the timer, but then
everybody pays the overhead of maintaining this extra state, and that
is undesired.
The only other option that I could see is the external timer_active
variable, which I tried to kill before. I would love a nicer interface
for this seemingly simple 'problem' but alas.
Fixes: 272325c4821f ("perf: Fix mux_interval hrtimer wreckage")
Fixes: 77a4d1a1b9a1 ("sched: Cleanup bandwidth timers")
Cc: pjt@google.com
Cc: tglx@linutronix.de
Cc: klamm@yandex-team.ru
Cc: mingo@kernel.org
Cc: bsegall@google.com
Cc: hpa@zytor.com
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20150514102311.GX21418@twins.programming.kicks-ass.net
2015-05-14 10:23:11 +00:00
|
|
|
if (idle)
|
|
|
|
cfs_b->period_active = 0;
|
2019-01-07 12:52:31 +00:00
|
|
|
raw_spin_unlock_irqrestore(&cfs_b->lock, flags);
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
return idle ? HRTIMER_NORESTART : HRTIMER_RESTART;
|
|
|
|
}
|
|
|
|
|
|
|
|
void init_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
|
|
|
|
{
|
|
|
|
raw_spin_lock_init(&cfs_b->lock);
|
|
|
|
cfs_b->runtime = 0;
|
|
|
|
cfs_b->quota = RUNTIME_INF;
|
|
|
|
cfs_b->period = ns_to_ktime(default_cfs_period());
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&cfs_b->throttled_cfs_rq);
|
sched,perf: Fix periodic timers
In the below two commits (see Fixes) we have periodic timers that can
stop themselves when they're no longer required, but need to be
(re)-started when their idle condition changes.
Further complications is that we want the timer handler to always do
the forward such that it will always correctly deal with the overruns,
and we do not want to race such that the handler has already decided
to stop, but the (external) restart sees the timer still active and we
end up with a 'lost' timer.
The problem with the current code is that the re-start can come before
the callback does the forward, at which point the forward from the
callback will WARN about forwarding an enqueued timer.
Now, conceptually its easy to detect if you're before or after the fwd
by comparing the expiration time against the current time. Of course,
that's expensive (and racy) because we don't have the current time.
Alternatively one could cache this state inside the timer, but then
everybody pays the overhead of maintaining this extra state, and that
is undesired.
The only other option that I could see is the external timer_active
variable, which I tried to kill before. I would love a nicer interface
for this seemingly simple 'problem' but alas.
Fixes: 272325c4821f ("perf: Fix mux_interval hrtimer wreckage")
Fixes: 77a4d1a1b9a1 ("sched: Cleanup bandwidth timers")
Cc: pjt@google.com
Cc: tglx@linutronix.de
Cc: klamm@yandex-team.ru
Cc: mingo@kernel.org
Cc: bsegall@google.com
Cc: hpa@zytor.com
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20150514102311.GX21418@twins.programming.kicks-ass.net
2015-05-14 10:23:11 +00:00
|
|
|
hrtimer_init(&cfs_b->period_timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS_PINNED);
|
2011-10-25 08:00:11 +00:00
|
|
|
cfs_b->period_timer.function = sched_cfs_period_timer;
|
|
|
|
hrtimer_init(&cfs_b->slack_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
|
|
|
|
cfs_b->slack_timer.function = sched_cfs_slack_timer;
|
sched/fair: Fix throttle_list starvation with low CFS quota
With a very low cpu.cfs_quota_us setting, such as the minimum of 1000,
distribute_cfs_runtime may not empty the throttled_list before it runs
out of runtime to distribute. In that case, due to the change from
c06f04c7048 to put throttled entries at the head of the list, later entries
on the list will starve. Essentially, the same X processes will get pulled
off the list, given CPU time and then, when expired, get put back on the
head of the list where distribute_cfs_runtime will give runtime to the same
set of processes leaving the rest.
Fix the issue by setting a bit in struct cfs_bandwidth when
distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can
decide to put the throttled entry on the tail or the head of the list. The
bit is set/cleared by the callers of distribute_cfs_runtime while they hold
cfs_bandwidth->lock.
This is easy to reproduce with a handful of CPU consumers. I use 'crash' on
the live system. In some cases you can simply look at the throttled list and
see the later entries are not changing:
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -976050
2 ffff90b56cb2cc00 -484925
3 ffff90b56cb2bc00 -658814
4 ffff90b56cb2ba00 -275365
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3
1 ffff90b56cb2d200 -994147
2 ffff90b56cb2cc00 -306051
3 ffff90b56cb2bc00 -961321
4 ffff90b56cb2ba00 -24490
5 ffff90b166a45600 -135138
6 ffff90b56cb2da00 -282505
7 ffff90b56cb2e000 -148065
8 ffff90b56cb2fa00 -872591
9 ffff90b56cb2c000 -84687
10 ffff90b56cb2f000 -87237
11 ffff90b166a40a00 -164582
Sometimes it is easier to see by finding a process getting starved and looking
at the sched_info:
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
crash> task ffff8eb765994500 sched_info
PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest"
sched_info = {
pcount = 8,
run_delay = 697094208,
last_arrival = 240260125039,
last_queued = 240260327513
},
Signed-off-by: Phil Auld <pauld@redhat.com>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop")
Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-10-08 14:36:40 +00:00
|
|
|
cfs_b->distribute_running = 0;
|
2019-06-06 17:21:01 +00:00
|
|
|
cfs_b->slack_started = false;
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void init_cfs_rq_runtime(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
cfs_rq->runtime_enabled = 0;
|
|
|
|
INIT_LIST_HEAD(&cfs_rq->throttled_list);
|
|
|
|
}
|
|
|
|
|
sched: Cleanup bandwidth timers
Roman reported a 3 cpu lockup scenario involving __start_cfs_bandwidth().
The more I look at that code the more I'm convinced its crack, that
entire __start_cfs_bandwidth() thing is brain melting, we don't need to
cancel a timer before starting it, *hrtimer_start*() will happily remove
the timer for you if its still enqueued.
Removing that, removes a big part of the problem, no more ugly cancel
loop to get stuck in.
So now, if I understand things right, the entire reason you have this
cfs_b->lock guarded ->timer_active nonsense is to make sure we don't
accidentally lose the timer.
It appears to me that it should be possible to guarantee that same by
unconditionally (re)starting the timer when !queued. Because regardless
what hrtimer::function will return, if we beat it to (re)enqueue the
timer, it doesn't matter.
Now, because hrtimers don't come with any serialization guarantees we
must ensure both handler and (re)start loop serialize their access to
the hrtimer to avoid both trying to forward the timer at the same
time.
Update the rt bandwidth timer to match.
This effectively reverts: 09dc4ab03936 ("sched/fair: Fix
tg_set_cfs_bandwidth() deadlock on rq->lock").
Reported-by: Roman Gushchin <klamm@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ben Segall <bsegall@google.com>
Cc: Paul Turner <pjt@google.com>
Link: http://lkml.kernel.org/r/20150415095011.804589208@infradead.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-04-15 09:41:57 +00:00
|
|
|
void start_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
|
2011-10-25 08:00:11 +00:00
|
|
|
{
|
sched,perf: Fix periodic timers
In the below two commits (see Fixes) we have periodic timers that can
stop themselves when they're no longer required, but need to be
(re)-started when their idle condition changes.
Further complications is that we want the timer handler to always do
the forward such that it will always correctly deal with the overruns,
and we do not want to race such that the handler has already decided
to stop, but the (external) restart sees the timer still active and we
end up with a 'lost' timer.
The problem with the current code is that the re-start can come before
the callback does the forward, at which point the forward from the
callback will WARN about forwarding an enqueued timer.
Now, conceptually its easy to detect if you're before or after the fwd
by comparing the expiration time against the current time. Of course,
that's expensive (and racy) because we don't have the current time.
Alternatively one could cache this state inside the timer, but then
everybody pays the overhead of maintaining this extra state, and that
is undesired.
The only other option that I could see is the external timer_active
variable, which I tried to kill before. I would love a nicer interface
for this seemingly simple 'problem' but alas.
Fixes: 272325c4821f ("perf: Fix mux_interval hrtimer wreckage")
Fixes: 77a4d1a1b9a1 ("sched: Cleanup bandwidth timers")
Cc: pjt@google.com
Cc: tglx@linutronix.de
Cc: klamm@yandex-team.ru
Cc: mingo@kernel.org
Cc: bsegall@google.com
Cc: hpa@zytor.com
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20150514102311.GX21418@twins.programming.kicks-ass.net
2015-05-14 10:23:11 +00:00
|
|
|
lockdep_assert_held(&cfs_b->lock);
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2018-06-20 10:18:34 +00:00
|
|
|
if (cfs_b->period_active)
|
|
|
|
return;
|
|
|
|
|
|
|
|
cfs_b->period_active = 1;
|
2019-08-20 18:40:55 +00:00
|
|
|
hrtimer_forward_now(&cfs_b->period_timer, cfs_b->period);
|
2018-06-20 10:18:34 +00:00
|
|
|
hrtimer_start_expires(&cfs_b->period_timer, HRTIMER_MODE_ABS_PINNED);
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b)
|
|
|
|
{
|
2014-12-25 06:51:21 +00:00
|
|
|
/* init_cfs_bandwidth() was not called */
|
|
|
|
if (!cfs_b->throttled_cfs_rq.next)
|
|
|
|
return;
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
hrtimer_cancel(&cfs_b->period_timer);
|
|
|
|
hrtimer_cancel(&cfs_b->slack_timer);
|
|
|
|
}
|
|
|
|
|
2017-05-04 13:31:22 +00:00
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Both these CPU hotplug callbacks race against unregister_fair_sched_group()
|
2017-05-04 13:31:22 +00:00
|
|
|
*
|
|
|
|
* The race is harmless, since modifying bandwidth settings of unhooked group
|
|
|
|
* bits doesn't do much.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* cpu online calback */
|
2014-06-25 08:19:42 +00:00
|
|
|
static void __maybe_unused update_runtime_enabled(struct rq *rq)
|
|
|
|
{
|
2017-05-04 13:31:22 +00:00
|
|
|
struct task_group *tg;
|
2014-06-25 08:19:42 +00:00
|
|
|
|
2017-05-04 13:31:22 +00:00
|
|
|
lockdep_assert_held(&rq->lock);
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(tg, &task_groups, list) {
|
|
|
|
struct cfs_bandwidth *cfs_b = &tg->cfs_bandwidth;
|
|
|
|
struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)];
|
2014-06-25 08:19:42 +00:00
|
|
|
|
|
|
|
raw_spin_lock(&cfs_b->lock);
|
|
|
|
cfs_rq->runtime_enabled = cfs_b->quota != RUNTIME_INF;
|
|
|
|
raw_spin_unlock(&cfs_b->lock);
|
|
|
|
}
|
2017-05-04 13:31:22 +00:00
|
|
|
rcu_read_unlock();
|
2014-06-25 08:19:42 +00:00
|
|
|
}
|
|
|
|
|
2017-05-04 13:31:22 +00:00
|
|
|
/* cpu offline callback */
|
2013-01-25 14:14:22 +00:00
|
|
|
static void __maybe_unused unthrottle_offline_cfs_rqs(struct rq *rq)
|
2011-10-25 08:00:11 +00:00
|
|
|
{
|
2017-05-04 13:31:22 +00:00
|
|
|
struct task_group *tg;
|
|
|
|
|
|
|
|
lockdep_assert_held(&rq->lock);
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(tg, &task_groups, list) {
|
|
|
|
struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)];
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
if (!cfs_rq->runtime_enabled)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* clock_task is not advancing so we just need to make sure
|
|
|
|
* there's some valid quota amount
|
|
|
|
*/
|
2014-05-19 22:49:45 +00:00
|
|
|
cfs_rq->runtime_remaining = 1;
|
2014-06-25 08:19:42 +00:00
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Offline rq is schedulable till CPU is completely disabled
|
2014-06-25 08:19:42 +00:00
|
|
|
* in take_cpu_down(), so we prevent new cfs throttling here.
|
|
|
|
*/
|
|
|
|
cfs_rq->runtime_enabled = 0;
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
if (cfs_rq_throttled(cfs_rq))
|
|
|
|
unthrottle_cfs_rq(cfs_rq);
|
|
|
|
}
|
2017-05-04 13:31:22 +00:00
|
|
|
rcu_read_unlock();
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#else /* CONFIG_CFS_BANDWIDTH */
|
2019-01-30 05:22:47 +00:00
|
|
|
|
|
|
|
static inline bool cfs_bandwidth_used(void)
|
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-11-18 17:27:06 +00:00
|
|
|
static void account_cfs_rq_runtime(struct cfs_rq *cfs_rq, u64 delta_exec) {}
|
2012-02-11 05:05:00 +00:00
|
|
|
static bool check_cfs_rq_runtime(struct cfs_rq *cfs_rq) { return false; }
|
2011-07-21 16:43:39 +00:00
|
|
|
static void check_enqueue_throttle(struct cfs_rq *cfs_rq) {}
|
2016-06-22 13:14:26 +00:00
|
|
|
static inline void sync_throttle(struct task_group *tg, int cpu) {}
|
2012-03-21 20:07:16 +00:00
|
|
|
static __always_inline void return_cfs_rq_runtime(struct cfs_rq *cfs_rq) {}
|
2011-07-21 16:43:33 +00:00
|
|
|
|
|
|
|
static inline int cfs_rq_throttled(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2011-07-21 16:43:36 +00:00
|
|
|
|
|
|
|
static inline int throttled_hierarchy(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int throttled_lb_pair(struct task_group *tg,
|
|
|
|
int src_cpu, int dest_cpu)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
void init_cfs_bandwidth(struct cfs_bandwidth *cfs_b) {}
|
|
|
|
|
|
|
|
#ifdef CONFIG_FAIR_GROUP_SCHED
|
|
|
|
static void init_cfs_rq_runtime(struct cfs_rq *cfs_rq) {}
|
2011-07-21 16:43:28 +00:00
|
|
|
#endif
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
static inline struct cfs_bandwidth *tg_cfs_bandwidth(struct task_group *tg)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
static inline void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b) {}
|
2014-06-25 08:19:42 +00:00
|
|
|
static inline void update_runtime_enabled(struct rq *rq) {}
|
2012-08-09 22:34:47 +00:00
|
|
|
static inline void unthrottle_offline_cfs_rqs(struct rq *rq) {}
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
#endif /* CONFIG_CFS_BANDWIDTH */
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/**************************************************
|
|
|
|
* CFS operations on tasks:
|
|
|
|
*/
|
|
|
|
|
2008-01-25 20:08:29 +00:00
|
|
|
#ifdef CONFIG_SCHED_HRTICK
|
|
|
|
static void hrtick_start_fair(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
struct sched_entity *se = &p->se;
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
|
|
|
|
2016-09-20 20:34:51 +00:00
|
|
|
SCHED_WARN_ON(task_rq(p) != rq);
|
2008-01-25 20:08:29 +00:00
|
|
|
|
2016-09-17 01:28:51 +00:00
|
|
|
if (rq->cfs.h_nr_running > 1) {
|
2008-01-25 20:08:29 +00:00
|
|
|
u64 slice = sched_slice(cfs_rq, se);
|
|
|
|
u64 ran = se->sum_exec_runtime - se->prev_sum_exec_runtime;
|
|
|
|
s64 delta = slice - ran;
|
|
|
|
|
|
|
|
if (delta < 0) {
|
|
|
|
if (rq->curr == p)
|
2014-06-28 20:03:57 +00:00
|
|
|
resched_curr(rq);
|
2008-01-25 20:08:29 +00:00
|
|
|
return;
|
|
|
|
}
|
2008-07-18 16:01:23 +00:00
|
|
|
hrtick_start(rq, delta);
|
2008-01-25 20:08:29 +00:00
|
|
|
}
|
|
|
|
}
|
2008-10-17 17:27:03 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* called from enqueue/dequeue and updates the hrtick when the
|
|
|
|
* current task is from our class and nr_running is low enough
|
|
|
|
* to matter.
|
|
|
|
*/
|
|
|
|
static void hrtick_update(struct rq *rq)
|
|
|
|
{
|
|
|
|
struct task_struct *curr = rq->curr;
|
|
|
|
|
2011-11-22 14:20:07 +00:00
|
|
|
if (!hrtick_enabled(rq) || curr->sched_class != &fair_sched_class)
|
2008-10-17 17:27:03 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
if (cfs_rq_of(&curr->se)->nr_running < sched_nr_latency)
|
|
|
|
hrtick_start_fair(rq, curr);
|
|
|
|
}
|
2008-06-24 18:09:43 +00:00
|
|
|
#else /* !CONFIG_SCHED_HRTICK */
|
2008-01-25 20:08:29 +00:00
|
|
|
static inline void
|
|
|
|
hrtick_start_fair(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
}
|
2008-10-17 17:27:03 +00:00
|
|
|
|
|
|
|
static inline void hrtick_update(struct rq *rq)
|
|
|
|
{
|
|
|
|
}
|
2008-01-25 20:08:29 +00:00
|
|
|
#endif
|
|
|
|
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
static inline unsigned long cpu_util(int cpu);
|
|
|
|
|
|
|
|
static inline bool cpu_overutilized(int cpu)
|
|
|
|
{
|
2019-06-04 07:01:52 +00:00
|
|
|
return !fits_capacity(cpu_util(cpu), capacity_of(cpu));
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void update_overutilized_status(struct rq *rq)
|
|
|
|
{
|
2019-06-04 11:14:58 +00:00
|
|
|
if (!READ_ONCE(rq->rd->overutilized) && cpu_overutilized(rq->cpu)) {
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
WRITE_ONCE(rq->rd->overutilized, SG_OVERUTILIZED);
|
2019-06-04 11:14:58 +00:00
|
|
|
trace_sched_overutilized_tp(rq->rd, SG_OVERUTILIZED);
|
|
|
|
}
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline void update_overutilized_status(struct rq *rq) { }
|
|
|
|
#endif
|
|
|
|
|
2020-01-08 08:27:04 +00:00
|
|
|
/* Runqueue only has SCHED_IDLE tasks enqueued */
|
|
|
|
static int sched_idle_rq(struct rq *rq)
|
|
|
|
{
|
|
|
|
return unlikely(rq->nr_running == rq->cfs.idle_h_nr_running &&
|
|
|
|
rq->nr_running);
|
|
|
|
}
|
|
|
|
|
2020-01-20 05:59:05 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2020-01-08 08:27:04 +00:00
|
|
|
static int sched_idle_cpu(int cpu)
|
|
|
|
{
|
|
|
|
return sched_idle_rq(cpu_rq(cpu));
|
|
|
|
}
|
2020-01-20 05:59:05 +00:00
|
|
|
#endif
|
2020-01-08 08:27:04 +00:00
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* The enqueue_task method is called before nr_running is
|
|
|
|
* increased. Here we update the fair scheduling stats and
|
|
|
|
* then put the task into the rbtree:
|
|
|
|
*/
|
2010-01-20 20:58:57 +00:00
|
|
|
static void
|
2010-03-24 15:38:48 +00:00
|
|
|
enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq;
|
2008-02-25 16:34:02 +00:00
|
|
|
struct sched_entity *se = &p->se;
|
2019-06-26 05:06:29 +00:00
|
|
|
int idle_h_nr_running = task_has_idle_policy(p);
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2018-05-24 14:10:23 +00:00
|
|
|
/*
|
|
|
|
* The code below (indirectly) updates schedutil which looks at
|
|
|
|
* the cfs_rq utilization to select a frequency.
|
|
|
|
* Let's add the task's estimated utilization to the cfs_rq's
|
|
|
|
* estimated utilization, before we update schedutil.
|
|
|
|
*/
|
|
|
|
util_est_enqueue(&rq->cfs, p);
|
|
|
|
|
2016-09-09 21:59:33 +00:00
|
|
|
/*
|
|
|
|
* If in_iowait is set, the code below may not trigger any cpufreq
|
|
|
|
* utilization updates, so do it here explicitly with the IOWAIT flag
|
|
|
|
* passed.
|
|
|
|
*/
|
|
|
|
if (p->in_iowait)
|
sched: cpufreq: Allow remote cpufreq callbacks
With Android UI and benchmarks the latency of cpufreq response to
certain scheduling events can become very critical. Currently, callbacks
into cpufreq governors are only made from the scheduler if the target
CPU of the event is the same as the current CPU. This means there are
certain situations where a target CPU may not run the cpufreq governor
for some time.
One testcase to show this behavior is where a task starts running on
CPU0, then a new task is also spawned on CPU0 by a task on CPU1. If the
system is configured such that the new tasks should receive maximum
demand initially, this should result in CPU0 increasing frequency
immediately. But because of the above mentioned limitation though, this
does not occur.
This patch updates the scheduler core to call the cpufreq callbacks for
remote CPUs as well.
The schedutil, ondemand and conservative governors are updated to
process cpufreq utilization update hooks called for remote CPUs where
the remote CPU is managed by the cpufreq policy of the local CPU.
The intel_pstate driver is updated to always reject remote callbacks.
This is tested with couple of usecases (Android: hackbench, recentfling,
galleryfling, vellamo, Ubuntu: hackbench) on ARM hikey board (64 bit
octa-core, single policy). Only galleryfling showed minor improvements,
while others didn't had much deviation.
The reason being that this patch only targets a corner case, where
following are required to be true to improve performance and that
doesn't happen too often with these tests:
- Task is migrated to another CPU.
- The task has high demand, and should take the target CPU to higher
OPPs.
- And the target CPU doesn't call into the cpufreq governor until the
next tick.
Based on initial work from Steve Muckle.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Saravana Kannan <skannan@codeaurora.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-28 06:46:38 +00:00
|
|
|
cpufreq_update_util(rq, SCHED_CPUFREQ_IOWAIT);
|
2016-09-09 21:59:33 +00:00
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
for_each_sched_entity(se) {
|
2008-02-25 16:34:02 +00:00
|
|
|
if (se->on_rq)
|
2007-07-09 16:51:58 +00:00
|
|
|
break;
|
|
|
|
cfs_rq = cfs_rq_of(se);
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
enqueue_entity(cfs_rq, se, flags);
|
2011-07-21 16:43:33 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* end evaluation on encountering a throttled cfs_rq
|
|
|
|
*
|
|
|
|
* note: in the case of encountering a throttled cfs_rq we will
|
|
|
|
* post the final h_nr_running increment below.
|
2016-06-16 16:51:48 +00:00
|
|
|
*/
|
2011-07-21 16:43:33 +00:00
|
|
|
if (cfs_rq_throttled(cfs_rq))
|
|
|
|
break;
|
2011-07-21 16:43:27 +00:00
|
|
|
cfs_rq->h_nr_running++;
|
2019-06-26 05:06:29 +00:00
|
|
|
cfs_rq->idle_h_nr_running += idle_h_nr_running;
|
2011-07-21 16:43:33 +00:00
|
|
|
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
flags = ENQUEUE_WAKEUP;
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
2008-01-25 20:08:29 +00:00
|
|
|
|
2010-11-15 23:47:00 +00:00
|
|
|
for_each_sched_entity(se) {
|
2011-07-22 01:14:31 +00:00
|
|
|
cfs_rq = cfs_rq_of(se);
|
2011-07-21 16:43:27 +00:00
|
|
|
cfs_rq->h_nr_running++;
|
2019-06-26 05:06:29 +00:00
|
|
|
cfs_rq->idle_h_nr_running += idle_h_nr_running;
|
2010-11-15 23:47:00 +00:00
|
|
|
|
2011-07-21 16:43:33 +00:00
|
|
|
if (cfs_rq_throttled(cfs_rq))
|
|
|
|
break;
|
|
|
|
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq, se, UPDATE_TG);
|
2017-05-06 13:59:54 +00:00
|
|
|
update_cfs_group(se);
|
2010-11-15 23:47:00 +00:00
|
|
|
}
|
|
|
|
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
if (!se) {
|
2014-05-08 23:00:14 +00:00
|
|
|
add_nr_running(rq, 1);
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
/*
|
|
|
|
* Since new tasks are assigned an initial util_avg equal to
|
|
|
|
* half of the spare capacity of their CPU, tiny tasks have the
|
|
|
|
* ability to cross the overutilized threshold, which will
|
|
|
|
* result in the load balancer ruining all the task placement
|
|
|
|
* done by EAS. As a way to mitigate that effect, do not account
|
|
|
|
* for the first enqueue operation of new tasks during the
|
|
|
|
* overutilized flag detection.
|
|
|
|
*
|
|
|
|
* A better way of solving this problem would be to wait for
|
|
|
|
* the PELT signals of tasks to converge before taking them
|
|
|
|
* into account, but that is not straightforward to implement,
|
|
|
|
* and the following generally works well enough in practice.
|
|
|
|
*/
|
|
|
|
if (flags & ENQUEUE_WAKEUP)
|
|
|
|
update_overutilized_status(rq);
|
|
|
|
|
|
|
|
}
|
2015-07-15 00:04:36 +00:00
|
|
|
|
2019-01-30 05:22:47 +00:00
|
|
|
if (cfs_bandwidth_used()) {
|
|
|
|
/*
|
|
|
|
* When bandwidth control is enabled; the cfs_rq_throttled()
|
|
|
|
* breaks in the above iteration can result in incomplete
|
|
|
|
* leaf list maintenance, resulting in triggering the assertion
|
|
|
|
* below.
|
|
|
|
*/
|
|
|
|
for_each_sched_entity(se) {
|
|
|
|
cfs_rq = cfs_rq_of(se);
|
|
|
|
|
|
|
|
if (list_add_leaf_cfs_rq(cfs_rq))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-30 13:41:04 +00:00
|
|
|
assert_list_leaf_cfs_rq(rq);
|
|
|
|
|
2008-10-17 17:27:03 +00:00
|
|
|
hrtick_update(rq);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2011-04-14 17:30:53 +00:00
|
|
|
static void set_next_buddy(struct sched_entity *se);
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* The dequeue_task method is called before nr_running is
|
|
|
|
* decreased. We remove the task from the rbtree and
|
|
|
|
* update the fair scheduling stats:
|
|
|
|
*/
|
2010-03-24 15:38:48 +00:00
|
|
|
static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq;
|
2008-02-25 16:34:02 +00:00
|
|
|
struct sched_entity *se = &p->se;
|
2011-04-14 17:30:53 +00:00
|
|
|
int task_sleep = flags & DEQUEUE_SLEEP;
|
2019-06-26 05:06:29 +00:00
|
|
|
int idle_h_nr_running = task_has_idle_policy(p);
|
2020-01-08 08:27:04 +00:00
|
|
|
bool was_sched_idle = sched_idle_rq(rq);
|
2007-07-09 16:51:58 +00:00
|
|
|
|
|
|
|
for_each_sched_entity(se) {
|
|
|
|
cfs_rq = cfs_rq_of(se);
|
2010-03-24 15:38:48 +00:00
|
|
|
dequeue_entity(cfs_rq, se, flags);
|
2011-07-21 16:43:33 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* end evaluation on encountering a throttled cfs_rq
|
|
|
|
*
|
|
|
|
* note: in the case of encountering a throttled cfs_rq we will
|
|
|
|
* post the final h_nr_running decrement below.
|
|
|
|
*/
|
|
|
|
if (cfs_rq_throttled(cfs_rq))
|
|
|
|
break;
|
2011-07-21 16:43:27 +00:00
|
|
|
cfs_rq->h_nr_running--;
|
2019-06-26 05:06:29 +00:00
|
|
|
cfs_rq->idle_h_nr_running -= idle_h_nr_running;
|
2010-11-15 23:47:00 +00:00
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/* Don't dequeue parent if it has other entities besides us */
|
2011-04-14 17:30:53 +00:00
|
|
|
if (cfs_rq->load.weight) {
|
2016-06-16 12:57:15 +00:00
|
|
|
/* Avoid re-evaluating load for this entity: */
|
|
|
|
se = parent_entity(se);
|
2011-04-14 17:30:53 +00:00
|
|
|
/*
|
|
|
|
* Bias pick_next to pick a task from this cfs_rq, as
|
|
|
|
* p is sleeping when it is within its sched_slice.
|
|
|
|
*/
|
2016-06-16 12:57:15 +00:00
|
|
|
if (task_sleep && se && !throttled_hierarchy(cfs_rq))
|
|
|
|
set_next_buddy(se);
|
2007-07-09 16:51:58 +00:00
|
|
|
break;
|
2011-04-14 17:30:53 +00:00
|
|
|
}
|
2010-03-24 15:38:48 +00:00
|
|
|
flags |= DEQUEUE_SLEEP;
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
2008-01-25 20:08:29 +00:00
|
|
|
|
2010-11-15 23:47:00 +00:00
|
|
|
for_each_sched_entity(se) {
|
2011-07-22 01:14:31 +00:00
|
|
|
cfs_rq = cfs_rq_of(se);
|
2011-07-21 16:43:27 +00:00
|
|
|
cfs_rq->h_nr_running--;
|
2019-06-26 05:06:29 +00:00
|
|
|
cfs_rq->idle_h_nr_running -= idle_h_nr_running;
|
2010-11-15 23:47:00 +00:00
|
|
|
|
2011-07-21 16:43:33 +00:00
|
|
|
if (cfs_rq_throttled(cfs_rq))
|
|
|
|
break;
|
|
|
|
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq, se, UPDATE_TG);
|
2017-05-06 13:59:54 +00:00
|
|
|
update_cfs_group(se);
|
2010-11-15 23:47:00 +00:00
|
|
|
}
|
|
|
|
|
2015-07-15 00:04:36 +00:00
|
|
|
if (!se)
|
2014-05-08 23:00:14 +00:00
|
|
|
sub_nr_running(rq, 1);
|
2015-07-15 00:04:36 +00:00
|
|
|
|
2020-01-08 08:27:04 +00:00
|
|
|
/* balance early to pull high priority tasks */
|
|
|
|
if (unlikely(!was_sched_idle && sched_idle_rq(rq)))
|
|
|
|
rq->next_balance = jiffies;
|
|
|
|
|
sched/fair: Add util_est on top of PELT
The util_avg signal computed by PELT is too variable for some use-cases.
For example, a big task waking up after a long sleep period will have its
utilization almost completely decayed. This introduces some latency before
schedutil will be able to pick the best frequency to run a task.
The same issue can affect task placement. Indeed, since the task
utilization is already decayed at wakeup, when the task is enqueued in a
CPU, this can result in a CPU running a big task as being temporarily
represented as being almost empty. This leads to a race condition where
other tasks can be potentially allocated on a CPU which just started to run
a big task which slept for a relatively long period.
Moreover, the PELT utilization of a task can be updated every [ms], thus
making it a continuously changing value for certain longer running
tasks. This means that the instantaneous PELT utilization of a RUNNING
task is not really meaningful to properly support scheduler decisions.
For all these reasons, a more stable signal can do a better job of
representing the expected/estimated utilization of a task/cfs_rq.
Such a signal can be easily created on top of PELT by still using it as
an estimator which produces values to be aggregated on meaningful
events.
This patch adds a simple implementation of util_est, a new signal built on
top of PELT's util_avg where:
util_est(task) = max(task::util_avg, f(task::util_avg@dequeue))
This allows to remember how big a task has been reported by PELT in its
previous activations via f(task::util_avg@dequeue), which is the new
_task_util_est(struct task_struct*) function added by this patch.
If a task should change its behavior and it runs longer in a new
activation, after a certain time its util_est will just track the
original PELT signal (i.e. task::util_avg).
The estimated utilization of cfs_rq is defined only for root ones.
That's because the only sensible consumer of this signal are the
scheduler and schedutil when looking for the overall CPU utilization
due to FAIR tasks.
For this reason, the estimated utilization of a root cfs_rq is simply
defined as:
util_est(cfs_rq) = max(cfs_rq::util_avg, cfs_rq::util_est::enqueued)
where:
cfs_rq::util_est::enqueued = sum(_task_util_est(task))
for each RUNNABLE task on that root cfs_rq
It's worth noting that the estimated utilization is tracked only for
objects of interests, specifically:
- Tasks: to better support tasks placement decisions
- root cfs_rqs: to better support both tasks placement decisions as
well as frequencies selection
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Paul Turner <pjt@google.com>
Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@android.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/20180309095245.11071-2-patrick.bellasi@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-09 09:52:42 +00:00
|
|
|
util_est_dequeue(&rq->cfs, p, task_sleep);
|
2008-10-17 17:27:03 +00:00
|
|
|
hrtick_update(rq);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2008-01-25 20:08:09 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2016-05-09 08:38:05 +00:00
|
|
|
|
|
|
|
/* Working cpumask for: load_balance, load_balance_newidle. */
|
|
|
|
DEFINE_PER_CPU(cpumask_var_t, load_balance_mask);
|
|
|
|
DEFINE_PER_CPU(cpumask_var_t, select_idle_mask);
|
|
|
|
|
2016-04-19 15:36:51 +00:00
|
|
|
#ifdef CONFIG_NO_HZ_COMMON
|
2017-12-21 10:20:23 +00:00
|
|
|
|
|
|
|
static struct {
|
|
|
|
cpumask_var_t idle_cpus_mask;
|
|
|
|
atomic_t nr_cpus;
|
2018-02-13 10:31:17 +00:00
|
|
|
int has_blocked; /* Idle CPUS has blocked load */
|
2017-12-21 10:20:23 +00:00
|
|
|
unsigned long next_balance; /* in jiffy units */
|
2018-02-13 10:31:17 +00:00
|
|
|
unsigned long next_blocked; /* Next update of blocked load in jiffies */
|
2017-12-21 10:20:23 +00:00
|
|
|
} nohz ____cacheline_aligned;
|
|
|
|
|
2016-04-19 15:36:51 +00:00
|
|
|
#endif /* CONFIG_NO_HZ_COMMON */
|
2015-04-14 11:19:42 +00:00
|
|
|
|
2019-10-18 13:26:33 +00:00
|
|
|
static unsigned long cpu_load(struct rq *rq)
|
|
|
|
{
|
|
|
|
return cfs_rq_load_avg(&rq->cfs);
|
|
|
|
}
|
|
|
|
|
2019-10-22 16:46:38 +00:00
|
|
|
/*
|
|
|
|
* cpu_load_without - compute CPU load without any contributions from *p
|
|
|
|
* @cpu: the CPU which load is requested
|
|
|
|
* @p: the task which load should be discounted
|
|
|
|
*
|
|
|
|
* The load of a CPU is defined by the load of tasks currently enqueued on that
|
|
|
|
* CPU as well as tasks which are currently sleeping after an execution on that
|
|
|
|
* CPU.
|
|
|
|
*
|
|
|
|
* This method returns the load of the specified CPU by discounting the load of
|
|
|
|
* the specified task, whenever the task is currently contributing to the CPU
|
|
|
|
* load.
|
|
|
|
*/
|
|
|
|
static unsigned long cpu_load_without(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq;
|
|
|
|
unsigned int load;
|
|
|
|
|
|
|
|
/* Task has no contribution or is new */
|
|
|
|
if (cpu_of(rq) != task_cpu(p) || !READ_ONCE(p->se.avg.last_update_time))
|
|
|
|
return cpu_load(rq);
|
|
|
|
|
|
|
|
cfs_rq = &rq->cfs;
|
|
|
|
load = READ_ONCE(cfs_rq->avg.load_avg);
|
|
|
|
|
|
|
|
/* Discount task's util from CPU's util */
|
|
|
|
lsub_positive(&load, task_h_load(p));
|
|
|
|
|
|
|
|
return load;
|
|
|
|
}
|
|
|
|
|
2014-05-26 22:19:38 +00:00
|
|
|
static unsigned long capacity_of(int cpu)
|
2011-10-25 08:00:11 +00:00
|
|
|
{
|
2014-05-26 22:19:38 +00:00
|
|
|
return cpu_rq(cpu)->cpu_capacity;
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
2016-05-12 07:19:59 +00:00
|
|
|
static void record_wakee(struct task_struct *p)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Only decay a single time; tasks that have less then 1 wakeup per
|
|
|
|
* jiffy will not have built up many flips.
|
|
|
|
*/
|
|
|
|
if (time_after(jiffies, current->wakee_flip_decay_ts + HZ)) {
|
|
|
|
current->wakee_flips >>= 1;
|
|
|
|
current->wakee_flip_decay_ts = jiffies;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (current->last_wakee != p) {
|
|
|
|
current->last_wakee = p;
|
|
|
|
current->wakee_flips++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-14 15:39:50 +00:00
|
|
|
/*
|
|
|
|
* Detect M:N waker/wakee relationships via a switching-frequency heuristic.
|
2016-05-12 07:19:59 +00:00
|
|
|
*
|
2015-07-14 15:39:50 +00:00
|
|
|
* A waker of many should wake a different task than the one last awakened
|
2016-05-12 07:19:59 +00:00
|
|
|
* at a frequency roughly N times higher than one of its wakees.
|
|
|
|
*
|
|
|
|
* In order to determine whether we should let the load spread vs consolidating
|
|
|
|
* to shared cache, we look for a minimum 'flip' frequency of llc_size in one
|
|
|
|
* partner, and a factor of lls_size higher frequency in the other.
|
|
|
|
*
|
|
|
|
* With both conditions met, we can be relatively sure that the relationship is
|
|
|
|
* non-monogamous, with partner count exceeding socket size.
|
|
|
|
*
|
|
|
|
* Waker/wakee being client/server, worker/dispatcher, interrupt source or
|
|
|
|
* whatever is irrelevant, spread criteria is apparent partner count exceeds
|
|
|
|
* socket size.
|
2015-07-14 15:39:50 +00:00
|
|
|
*/
|
sched: Implement smarter wake-affine logic
The wake-affine scheduler feature is currently always trying to pull
the wakee close to the waker. In theory this should be beneficial if
the waker's CPU caches hot data for the wakee, and it's also beneficial
in the extreme ping-pong high context switch rate case.
Testing shows it can benefit hackbench up to 15%.
However, the feature is somewhat blind, from which some workloads
such as pgbench suffer. It's also time-consuming algorithmically.
Testing shows it can damage pgbench up to 50% - far more than the
benefit it brings in the best case.
So wake-affine should be smarter and it should realize when to
stop its thankless effort at trying to find a suitable CPU to wake on.
This patch introduces 'wakee_flips', which will be increased each
time the task flips (switches) its wakee target.
So a high 'wakee_flips' value means the task has more than one
wakee, and the bigger the number, the higher the wakeup frequency.
Now when making the decision on whether to pull or not, pay attention to
the wakee with a high 'wakee_flips', pulling such a task may benefit
the wakee. Also imply that the waker will face cruel competition later,
it could be very cruel or very fast depends on the story behind
'wakee_flips', waker therefore suffers.
Furthermore, if waker also has a high 'wakee_flips', that implies that
multiple tasks rely on it, then waker's higher latency will damage all
of them, so pulling wakee seems to be a bad deal.
Thus, when 'waker->wakee_flips / wakee->wakee_flips' becomes
higher and higher, the cost of pulling seems to be worse and worse.
The patch therefore helps the wake-affine feature to stop its pulling
work when:
wakee->wakee_flips > factor &&
waker->wakee_flips > (factor * wakee->wakee_flips)
The 'factor' here is the number of CPUs in the current CPU's NUMA node,
so a bigger node will lead to more pulling since the trial becomes more
severe.
After applying the patch, pgbench shows up to 40% improvements and no regressions.
Tested with 12 cpu x86 server and tip 3.10.0-rc7.
The percentages in the final column highlight the areas with the biggest wins,
all other areas improved as well:
pgbench base smart
| db_size | clients | tps | | tps |
+---------+---------+-------+ +-------+
| 22 MB | 1 | 10598 | | 10796 |
| 22 MB | 2 | 21257 | | 21336 |
| 22 MB | 4 | 41386 | | 41622 |
| 22 MB | 8 | 51253 | | 57932 |
| 22 MB | 12 | 48570 | | 54000 |
| 22 MB | 16 | 46748 | | 55982 | +19.75%
| 22 MB | 24 | 44346 | | 55847 | +25.93%
| 22 MB | 32 | 43460 | | 54614 | +25.66%
| 7484 MB | 1 | 8951 | | 9193 |
| 7484 MB | 2 | 19233 | | 19240 |
| 7484 MB | 4 | 37239 | | 37302 |
| 7484 MB | 8 | 46087 | | 50018 |
| 7484 MB | 12 | 42054 | | 48763 |
| 7484 MB | 16 | 40765 | | 51633 | +26.66%
| 7484 MB | 24 | 37651 | | 52377 | +39.11%
| 7484 MB | 32 | 37056 | | 51108 | +37.92%
| 15 GB | 1 | 8845 | | 9104 |
| 15 GB | 2 | 19094 | | 19162 |
| 15 GB | 4 | 36979 | | 36983 |
| 15 GB | 8 | 46087 | | 49977 |
| 15 GB | 12 | 41901 | | 48591 |
| 15 GB | 16 | 40147 | | 50651 | +26.16%
| 15 GB | 24 | 37250 | | 52365 | +40.58%
| 15 GB | 32 | 36470 | | 50015 | +37.14%
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/51D50057.9000809@linux.vnet.ibm.com
[ Improved the changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-04 04:55:51 +00:00
|
|
|
static int wake_wide(struct task_struct *p)
|
|
|
|
{
|
2015-07-14 15:39:50 +00:00
|
|
|
unsigned int master = current->wakee_flips;
|
|
|
|
unsigned int slave = p->wakee_flips;
|
2013-07-04 04:56:46 +00:00
|
|
|
int factor = this_cpu_read(sd_llc_size);
|
sched: Implement smarter wake-affine logic
The wake-affine scheduler feature is currently always trying to pull
the wakee close to the waker. In theory this should be beneficial if
the waker's CPU caches hot data for the wakee, and it's also beneficial
in the extreme ping-pong high context switch rate case.
Testing shows it can benefit hackbench up to 15%.
However, the feature is somewhat blind, from which some workloads
such as pgbench suffer. It's also time-consuming algorithmically.
Testing shows it can damage pgbench up to 50% - far more than the
benefit it brings in the best case.
So wake-affine should be smarter and it should realize when to
stop its thankless effort at trying to find a suitable CPU to wake on.
This patch introduces 'wakee_flips', which will be increased each
time the task flips (switches) its wakee target.
So a high 'wakee_flips' value means the task has more than one
wakee, and the bigger the number, the higher the wakeup frequency.
Now when making the decision on whether to pull or not, pay attention to
the wakee with a high 'wakee_flips', pulling such a task may benefit
the wakee. Also imply that the waker will face cruel competition later,
it could be very cruel or very fast depends on the story behind
'wakee_flips', waker therefore suffers.
Furthermore, if waker also has a high 'wakee_flips', that implies that
multiple tasks rely on it, then waker's higher latency will damage all
of them, so pulling wakee seems to be a bad deal.
Thus, when 'waker->wakee_flips / wakee->wakee_flips' becomes
higher and higher, the cost of pulling seems to be worse and worse.
The patch therefore helps the wake-affine feature to stop its pulling
work when:
wakee->wakee_flips > factor &&
waker->wakee_flips > (factor * wakee->wakee_flips)
The 'factor' here is the number of CPUs in the current CPU's NUMA node,
so a bigger node will lead to more pulling since the trial becomes more
severe.
After applying the patch, pgbench shows up to 40% improvements and no regressions.
Tested with 12 cpu x86 server and tip 3.10.0-rc7.
The percentages in the final column highlight the areas with the biggest wins,
all other areas improved as well:
pgbench base smart
| db_size | clients | tps | | tps |
+---------+---------+-------+ +-------+
| 22 MB | 1 | 10598 | | 10796 |
| 22 MB | 2 | 21257 | | 21336 |
| 22 MB | 4 | 41386 | | 41622 |
| 22 MB | 8 | 51253 | | 57932 |
| 22 MB | 12 | 48570 | | 54000 |
| 22 MB | 16 | 46748 | | 55982 | +19.75%
| 22 MB | 24 | 44346 | | 55847 | +25.93%
| 22 MB | 32 | 43460 | | 54614 | +25.66%
| 7484 MB | 1 | 8951 | | 9193 |
| 7484 MB | 2 | 19233 | | 19240 |
| 7484 MB | 4 | 37239 | | 37302 |
| 7484 MB | 8 | 46087 | | 50018 |
| 7484 MB | 12 | 42054 | | 48763 |
| 7484 MB | 16 | 40765 | | 51633 | +26.66%
| 7484 MB | 24 | 37651 | | 52377 | +39.11%
| 7484 MB | 32 | 37056 | | 51108 | +37.92%
| 15 GB | 1 | 8845 | | 9104 |
| 15 GB | 2 | 19094 | | 19162 |
| 15 GB | 4 | 36979 | | 36983 |
| 15 GB | 8 | 46087 | | 49977 |
| 15 GB | 12 | 41901 | | 48591 |
| 15 GB | 16 | 40147 | | 50651 | +26.16%
| 15 GB | 24 | 37250 | | 52365 | +40.58%
| 15 GB | 32 | 36470 | | 50015 | +37.14%
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/51D50057.9000809@linux.vnet.ibm.com
[ Improved the changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-04 04:55:51 +00:00
|
|
|
|
2015-07-14 15:39:50 +00:00
|
|
|
if (master < slave)
|
|
|
|
swap(master, slave);
|
|
|
|
if (slave < factor || master < slave * factor)
|
|
|
|
return 0;
|
|
|
|
return 1;
|
sched: Implement smarter wake-affine logic
The wake-affine scheduler feature is currently always trying to pull
the wakee close to the waker. In theory this should be beneficial if
the waker's CPU caches hot data for the wakee, and it's also beneficial
in the extreme ping-pong high context switch rate case.
Testing shows it can benefit hackbench up to 15%.
However, the feature is somewhat blind, from which some workloads
such as pgbench suffer. It's also time-consuming algorithmically.
Testing shows it can damage pgbench up to 50% - far more than the
benefit it brings in the best case.
So wake-affine should be smarter and it should realize when to
stop its thankless effort at trying to find a suitable CPU to wake on.
This patch introduces 'wakee_flips', which will be increased each
time the task flips (switches) its wakee target.
So a high 'wakee_flips' value means the task has more than one
wakee, and the bigger the number, the higher the wakeup frequency.
Now when making the decision on whether to pull or not, pay attention to
the wakee with a high 'wakee_flips', pulling such a task may benefit
the wakee. Also imply that the waker will face cruel competition later,
it could be very cruel or very fast depends on the story behind
'wakee_flips', waker therefore suffers.
Furthermore, if waker also has a high 'wakee_flips', that implies that
multiple tasks rely on it, then waker's higher latency will damage all
of them, so pulling wakee seems to be a bad deal.
Thus, when 'waker->wakee_flips / wakee->wakee_flips' becomes
higher and higher, the cost of pulling seems to be worse and worse.
The patch therefore helps the wake-affine feature to stop its pulling
work when:
wakee->wakee_flips > factor &&
waker->wakee_flips > (factor * wakee->wakee_flips)
The 'factor' here is the number of CPUs in the current CPU's NUMA node,
so a bigger node will lead to more pulling since the trial becomes more
severe.
After applying the patch, pgbench shows up to 40% improvements and no regressions.
Tested with 12 cpu x86 server and tip 3.10.0-rc7.
The percentages in the final column highlight the areas with the biggest wins,
all other areas improved as well:
pgbench base smart
| db_size | clients | tps | | tps |
+---------+---------+-------+ +-------+
| 22 MB | 1 | 10598 | | 10796 |
| 22 MB | 2 | 21257 | | 21336 |
| 22 MB | 4 | 41386 | | 41622 |
| 22 MB | 8 | 51253 | | 57932 |
| 22 MB | 12 | 48570 | | 54000 |
| 22 MB | 16 | 46748 | | 55982 | +19.75%
| 22 MB | 24 | 44346 | | 55847 | +25.93%
| 22 MB | 32 | 43460 | | 54614 | +25.66%
| 7484 MB | 1 | 8951 | | 9193 |
| 7484 MB | 2 | 19233 | | 19240 |
| 7484 MB | 4 | 37239 | | 37302 |
| 7484 MB | 8 | 46087 | | 50018 |
| 7484 MB | 12 | 42054 | | 48763 |
| 7484 MB | 16 | 40765 | | 51633 | +26.66%
| 7484 MB | 24 | 37651 | | 52377 | +39.11%
| 7484 MB | 32 | 37056 | | 51108 | +37.92%
| 15 GB | 1 | 8845 | | 9104 |
| 15 GB | 2 | 19094 | | 19162 |
| 15 GB | 4 | 36979 | | 36983 |
| 15 GB | 8 | 46087 | | 49977 |
| 15 GB | 12 | 41901 | | 48591 |
| 15 GB | 16 | 40147 | | 50651 | +26.16%
| 15 GB | 24 | 37250 | | 52365 | +40.58%
| 15 GB | 32 | 36470 | | 50015 | +37.14%
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
Cc: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/51D50057.9000809@linux.vnet.ibm.com
[ Improved the changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-04 04:55:51 +00:00
|
|
|
}
|
|
|
|
|
2017-07-31 15:50:05 +00:00
|
|
|
/*
|
2017-09-27 09:35:30 +00:00
|
|
|
* The purpose of wake_affine() is to quickly determine on which CPU we can run
|
|
|
|
* soonest. For the purpose of speed we only consider the waking and previous
|
|
|
|
* CPU.
|
2017-07-31 15:50:05 +00:00
|
|
|
*
|
sched/fair: Only immediately migrate tasks due to interrupts if prev and target CPUs share cache
If waking from an idle CPU due to an interrupt then it's possible that
the waker task will be pulled to wake on the current CPU. Unfortunately,
depending on the type of interrupt and IRQ configuration, there may not
be a strong relationship between the CPU an interrupt was delivered on
and the CPU a task was running on. For example, the interrupts could all
be delivered to CPUs on one particular node due to the machine topology
or IRQ affinity configuration. Another example is an interrupt for an IO
completion which can be delivered to any CPU where there is no guarantee
the data is either cache hot or even local.
This patch was motivated by the observation that an IO workload was
being pulled cross-node on a frequent basis when IO completed. From a
wakeup latency perspective, it's still useful to know that an idle CPU is
immediately available for use but lets only consider an automatic migration
if the CPUs share cache to limit damage due to NUMA migrations. Migrations
may still occur if wake_affine_weight determines it's appropriate.
These are the throughput results for dbench running on ext4 comparing
4.15-rc3 and this patch on a 2-socket machine where interrupts due to IO
completions can happen on any CPU.
4.15.0-rc3 4.15.0-rc3
vanilla lessmigrate
Hmean 1 854.64 ( 0.00%) 865.01 ( 1.21%)
Hmean 2 1229.60 ( 0.00%) 1274.44 ( 3.65%)
Hmean 4 1591.81 ( 0.00%) 1628.08 ( 2.28%)
Hmean 8 1845.04 ( 0.00%) 1831.80 ( -0.72%)
Hmean 16 2038.61 ( 0.00%) 2091.44 ( 2.59%)
Hmean 32 2327.19 ( 0.00%) 2430.29 ( 4.43%)
Hmean 64 2570.61 ( 0.00%) 2568.54 ( -0.08%)
Hmean 128 2481.89 ( 0.00%) 2499.28 ( 0.70%)
Stddev 1 14.31 ( 0.00%) 5.35 ( 62.65%)
Stddev 2 21.29 ( 0.00%) 11.09 ( 47.92%)
Stddev 4 7.22 ( 0.00%) 6.80 ( 5.92%)
Stddev 8 26.70 ( 0.00%) 9.41 ( 64.76%)
Stddev 16 22.40 ( 0.00%) 20.01 ( 10.70%)
Stddev 32 45.13 ( 0.00%) 44.74 ( 0.85%)
Stddev 64 93.10 ( 0.00%) 93.18 ( -0.09%)
Stddev 128 184.28 ( 0.00%) 177.85 ( 3.49%)
Note the small increase in throughput for low thread counts but also
note that the standard deviation for each sample during the test run is
lower. The throughput figures for dbench can be misleading so the benchmark
is actually modified to time the latency of the processing of one load
file with many samples taken. The difference in latency is
4.15.0-rc3 4.15.0-rc3
vanilla lessmigrate
Amean 1 21.71 ( 0.00%) 21.47 ( 1.08%)
Amean 2 30.89 ( 0.00%) 29.58 ( 4.26%)
Amean 4 47.54 ( 0.00%) 46.61 ( 1.97%)
Amean 8 82.71 ( 0.00%) 82.81 ( -0.12%)
Amean 16 149.45 ( 0.00%) 145.01 ( 2.97%)
Amean 32 265.49 ( 0.00%) 248.43 ( 6.42%)
Amean 64 463.23 ( 0.00%) 463.55 ( -0.07%)
Amean 128 933.97 ( 0.00%) 935.50 ( -0.16%)
Stddev 1 1.58 ( 0.00%) 1.54 ( 2.26%)
Stddev 2 2.84 ( 0.00%) 2.95 ( -4.15%)
Stddev 4 6.78 ( 0.00%) 6.85 ( -0.99%)
Stddev 8 16.85 ( 0.00%) 16.37 ( 2.85%)
Stddev 16 41.59 ( 0.00%) 41.04 ( 1.32%)
Stddev 32 111.05 ( 0.00%) 105.11 ( 5.35%)
Stddev 64 285.94 ( 0.00%) 288.01 ( -0.72%)
Stddev 128 803.39 ( 0.00%) 809.73 ( -0.79%)
It's a small improvement which is not surprising given that migrations that
migrate to a different node as not that common. However, it is noticeable
in the CPU migration statistics which are reduced by 24%.
There was a query for v1 of this patch about NAS so here are the results
for C-class using MPI for parallelisation on the same machine
nas-mpi
4.15.0-rc3 4.15.0-rc3
vanilla noirq
Time cg.C 24.25 ( 0.00%) 23.17 ( 4.45%)
Time ep.C 8.22 ( 0.00%) 8.29 ( -0.85%)
Time ft.C 22.67 ( 0.00%) 20.34 ( 10.28%)
Time is.C 1.42 ( 0.00%) 1.47 ( -3.52%)
Time lu.C 55.62 ( 0.00%) 54.81 ( 1.46%)
Time mg.C 7.93 ( 0.00%) 7.91 ( 0.25%)
4.15.0-rc3 4.15.0-rc3
vanilla noirq-v1r1
User 3799.96 3748.34
System 672.10 626.15
Elapsed 91.91 79.49
lu.C sees a small gain, ft.C a large gain and ep.C and is.C see small
regressions but in terms of absolute time, the difference is small and
likely within run-to-run variance. System CPU usage is slightly reduced.
schbench from Facebook was also requested. This is a bit of a mixed bag but
it's important to note that this workload should not be heavily impacted
by wakeups from interrupt context.
4.15.0-rc3 4.15.0-rc3
vanilla noirq-v1r1
Lat 50.00th-qrtle-1 41.00 ( 0.00%) 41.00 ( 0.00%)
Lat 75.00th-qrtle-1 42.00 ( 0.00%) 42.00 ( 0.00%)
Lat 90.00th-qrtle-1 43.00 ( 0.00%) 44.00 ( -2.33%)
Lat 95.00th-qrtle-1 44.00 ( 0.00%) 46.00 ( -4.55%)
Lat 99.00th-qrtle-1 57.00 ( 0.00%) 58.00 ( -1.75%)
Lat 99.50th-qrtle-1 59.00 ( 0.00%) 59.00 ( 0.00%)
Lat 99.90th-qrtle-1 67.00 ( 0.00%) 78.00 ( -16.42%)
Lat 50.00th-qrtle-2 40.00 ( 0.00%) 51.00 ( -27.50%)
Lat 75.00th-qrtle-2 45.00 ( 0.00%) 56.00 ( -24.44%)
Lat 90.00th-qrtle-2 53.00 ( 0.00%) 59.00 ( -11.32%)
Lat 95.00th-qrtle-2 57.00 ( 0.00%) 61.00 ( -7.02%)
Lat 99.00th-qrtle-2 67.00 ( 0.00%) 71.00 ( -5.97%)
Lat 99.50th-qrtle-2 69.00 ( 0.00%) 74.00 ( -7.25%)
Lat 99.90th-qrtle-2 83.00 ( 0.00%) 77.00 ( 7.23%)
Lat 50.00th-qrtle-4 51.00 ( 0.00%) 51.00 ( 0.00%)
Lat 75.00th-qrtle-4 57.00 ( 0.00%) 56.00 ( 1.75%)
Lat 90.00th-qrtle-4 60.00 ( 0.00%) 59.00 ( 1.67%)
Lat 95.00th-qrtle-4 62.00 ( 0.00%) 62.00 ( 0.00%)
Lat 99.00th-qrtle-4 73.00 ( 0.00%) 72.00 ( 1.37%)
Lat 99.50th-qrtle-4 76.00 ( 0.00%) 74.00 ( 2.63%)
Lat 99.90th-qrtle-4 85.00 ( 0.00%) 78.00 ( 8.24%)
Lat 50.00th-qrtle-8 54.00 ( 0.00%) 58.00 ( -7.41%)
Lat 75.00th-qrtle-8 59.00 ( 0.00%) 62.00 ( -5.08%)
Lat 90.00th-qrtle-8 65.00 ( 0.00%) 66.00 ( -1.54%)
Lat 95.00th-qrtle-8 67.00 ( 0.00%) 70.00 ( -4.48%)
Lat 99.00th-qrtle-8 78.00 ( 0.00%) 79.00 ( -1.28%)
Lat 99.50th-qrtle-8 81.00 ( 0.00%) 80.00 ( 1.23%)
Lat 99.90th-qrtle-8 116.00 ( 0.00%) 83.00 ( 28.45%)
Lat 50.00th-qrtle-16 65.00 ( 0.00%) 64.00 ( 1.54%)
Lat 75.00th-qrtle-16 77.00 ( 0.00%) 71.00 ( 7.79%)
Lat 90.00th-qrtle-16 83.00 ( 0.00%) 82.00 ( 1.20%)
Lat 95.00th-qrtle-16 87.00 ( 0.00%) 87.00 ( 0.00%)
Lat 99.00th-qrtle-16 95.00 ( 0.00%) 96.00 ( -1.05%)
Lat 99.50th-qrtle-16 99.00 ( 0.00%) 103.00 ( -4.04%)
Lat 99.90th-qrtle-16 104.00 ( 0.00%) 122.00 ( -17.31%)
Lat 50.00th-qrtle-32 71.00 ( 0.00%) 73.00 ( -2.82%)
Lat 75.00th-qrtle-32 91.00 ( 0.00%) 92.00 ( -1.10%)
Lat 90.00th-qrtle-32 108.00 ( 0.00%) 107.00 ( 0.93%)
Lat 95.00th-qrtle-32 118.00 ( 0.00%) 115.00 ( 2.54%)
Lat 99.00th-qrtle-32 134.00 ( 0.00%) 129.00 ( 3.73%)
Lat 99.50th-qrtle-32 138.00 ( 0.00%) 133.00 ( 3.62%)
Lat 99.90th-qrtle-32 149.00 ( 0.00%) 146.00 ( 2.01%)
Lat 50.00th-qrtle-39 83.00 ( 0.00%) 81.00 ( 2.41%)
Lat 75.00th-qrtle-39 105.00 ( 0.00%) 102.00 ( 2.86%)
Lat 90.00th-qrtle-39 120.00 ( 0.00%) 119.00 ( 0.83%)
Lat 95.00th-qrtle-39 129.00 ( 0.00%) 128.00 ( 0.78%)
Lat 99.00th-qrtle-39 153.00 ( 0.00%) 149.00 ( 2.61%)
Lat 99.50th-qrtle-39 166.00 ( 0.00%) 156.00 ( 6.02%)
Lat 99.90th-qrtle-39 12304.00 ( 0.00%) 12848.00 ( -4.42%)
When heavily loaded (e.g. 99.50th-qrtle-39 indicates 39 threads), there
are small gains in many cases. Otherwise it depends on the quartile used
where it can be bad -- e.g. 75.00th-qrtle-2. However, even these results
are probably a co-incidence. For this workload, much depends on what node
the threads get placed on and their relative locality and not wakeups from
interrupt context. A larger component on how it behaves would be automatic
NUMA balancing where a fault incurred to measure locality would be a much
larger contributer to latency than the wakeup path.
This is the results from an almost identical machine that happened to run
the same test. They only differ in terms of storage which is irrelevant
for this test.
4.15.0-rc3 4.15.0-rc3
vanilla noirq-v1r1
Lat 50.00th-qrtle-1 41.00 ( 0.00%) 41.00 ( 0.00%)
Lat 75.00th-qrtle-1 42.00 ( 0.00%) 42.00 ( 0.00%)
Lat 90.00th-qrtle-1 44.00 ( 0.00%) 43.00 ( 2.27%)
Lat 95.00th-qrtle-1 53.00 ( 0.00%) 45.00 ( 15.09%)
Lat 99.00th-qrtle-1 59.00 ( 0.00%) 58.00 ( 1.69%)
Lat 99.50th-qrtle-1 60.00 ( 0.00%) 59.00 ( 1.67%)
Lat 99.90th-qrtle-1 86.00 ( 0.00%) 61.00 ( 29.07%)
Lat 50.00th-qrtle-2 52.00 ( 0.00%) 41.00 ( 21.15%)
Lat 75.00th-qrtle-2 57.00 ( 0.00%) 46.00 ( 19.30%)
Lat 90.00th-qrtle-2 60.00 ( 0.00%) 53.00 ( 11.67%)
Lat 95.00th-qrtle-2 62.00 ( 0.00%) 57.00 ( 8.06%)
Lat 99.00th-qrtle-2 73.00 ( 0.00%) 68.00 ( 6.85%)
Lat 99.50th-qrtle-2 74.00 ( 0.00%) 71.00 ( 4.05%)
Lat 99.90th-qrtle-2 90.00 ( 0.00%) 75.00 ( 16.67%)
Lat 50.00th-qrtle-4 57.00 ( 0.00%) 52.00 ( 8.77%)
Lat 75.00th-qrtle-4 60.00 ( 0.00%) 58.00 ( 3.33%)
Lat 90.00th-qrtle-4 62.00 ( 0.00%) 62.00 ( 0.00%)
Lat 95.00th-qrtle-4 65.00 ( 0.00%) 65.00 ( 0.00%)
Lat 99.00th-qrtle-4 76.00 ( 0.00%) 75.00 ( 1.32%)
Lat 99.50th-qrtle-4 77.00 ( 0.00%) 77.00 ( 0.00%)
Lat 99.90th-qrtle-4 87.00 ( 0.00%) 81.00 ( 6.90%)
Lat 50.00th-qrtle-8 59.00 ( 0.00%) 57.00 ( 3.39%)
Lat 75.00th-qrtle-8 63.00 ( 0.00%) 62.00 ( 1.59%)
Lat 90.00th-qrtle-8 66.00 ( 0.00%) 67.00 ( -1.52%)
Lat 95.00th-qrtle-8 68.00 ( 0.00%) 70.00 ( -2.94%)
Lat 99.00th-qrtle-8 79.00 ( 0.00%) 80.00 ( -1.27%)
Lat 99.50th-qrtle-8 80.00 ( 0.00%) 84.00 ( -5.00%)
Lat 99.90th-qrtle-8 84.00 ( 0.00%) 90.00 ( -7.14%)
Lat 50.00th-qrtle-16 65.00 ( 0.00%) 65.00 ( 0.00%)
Lat 75.00th-qrtle-16 77.00 ( 0.00%) 75.00 ( 2.60%)
Lat 90.00th-qrtle-16 84.00 ( 0.00%) 83.00 ( 1.19%)
Lat 95.00th-qrtle-16 88.00 ( 0.00%) 87.00 ( 1.14%)
Lat 99.00th-qrtle-16 97.00 ( 0.00%) 96.00 ( 1.03%)
Lat 99.50th-qrtle-16 100.00 ( 0.00%) 104.00 ( -4.00%)
Lat 99.90th-qrtle-16 110.00 ( 0.00%) 126.00 ( -14.55%)
Lat 50.00th-qrtle-32 70.00 ( 0.00%) 71.00 ( -1.43%)
Lat 75.00th-qrtle-32 92.00 ( 0.00%) 94.00 ( -2.17%)
Lat 90.00th-qrtle-32 110.00 ( 0.00%) 110.00 ( 0.00%)
Lat 95.00th-qrtle-32 121.00 ( 0.00%) 118.00 ( 2.48%)
Lat 99.00th-qrtle-32 135.00 ( 0.00%) 137.00 ( -1.48%)
Lat 99.50th-qrtle-32 140.00 ( 0.00%) 146.00 ( -4.29%)
Lat 99.90th-qrtle-32 150.00 ( 0.00%) 160.00 ( -6.67%)
Lat 50.00th-qrtle-39 80.00 ( 0.00%) 71.00 ( 11.25%)
Lat 75.00th-qrtle-39 102.00 ( 0.00%) 91.00 ( 10.78%)
Lat 90.00th-qrtle-39 118.00 ( 0.00%) 108.00 ( 8.47%)
Lat 95.00th-qrtle-39 128.00 ( 0.00%) 117.00 ( 8.59%)
Lat 99.00th-qrtle-39 149.00 ( 0.00%) 133.00 ( 10.74%)
Lat 99.50th-qrtle-39 160.00 ( 0.00%) 139.00 ( 13.12%)
Lat 99.90th-qrtle-39 13808.00 ( 0.00%) 4920.00 ( 64.37%)
Despite being nearly identical, it showed a variety of major gains so
I'm not convinced that heavy emphasis should be placed on this particular
workload in terms of evaluating this particular patch. Further evidence of
this is the fact that testing on a UMA machine showed small gains/losses
even though the patch should be a no-op on UMA.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20171219085947.13136-2-mgorman@techsingularity.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-19 08:59:47 +00:00
|
|
|
* wake_affine_idle() - only considers 'now', it check if the waking CPU is
|
|
|
|
* cache-affine and is (or will be) idle.
|
2017-10-06 07:23:24 +00:00
|
|
|
*
|
|
|
|
* wake_affine_weight() - considers the weight to reflect the average
|
|
|
|
* scheduling latency of the CPUs. This seems to work
|
|
|
|
* for the overloaded case.
|
2017-07-31 15:50:05 +00:00
|
|
|
*/
|
2018-01-30 10:45:53 +00:00
|
|
|
static int
|
2018-01-30 10:45:52 +00:00
|
|
|
wake_affine_idle(int this_cpu, int prev_cpu, int sync)
|
2017-07-31 15:50:05 +00:00
|
|
|
{
|
sched/fair: Only immediately migrate tasks due to interrupts if prev and target CPUs share cache
If waking from an idle CPU due to an interrupt then it's possible that
the waker task will be pulled to wake on the current CPU. Unfortunately,
depending on the type of interrupt and IRQ configuration, there may not
be a strong relationship between the CPU an interrupt was delivered on
and the CPU a task was running on. For example, the interrupts could all
be delivered to CPUs on one particular node due to the machine topology
or IRQ affinity configuration. Another example is an interrupt for an IO
completion which can be delivered to any CPU where there is no guarantee
the data is either cache hot or even local.
This patch was motivated by the observation that an IO workload was
being pulled cross-node on a frequent basis when IO completed. From a
wakeup latency perspective, it's still useful to know that an idle CPU is
immediately available for use but lets only consider an automatic migration
if the CPUs share cache to limit damage due to NUMA migrations. Migrations
may still occur if wake_affine_weight determines it's appropriate.
These are the throughput results for dbench running on ext4 comparing
4.15-rc3 and this patch on a 2-socket machine where interrupts due to IO
completions can happen on any CPU.
4.15.0-rc3 4.15.0-rc3
vanilla lessmigrate
Hmean 1 854.64 ( 0.00%) 865.01 ( 1.21%)
Hmean 2 1229.60 ( 0.00%) 1274.44 ( 3.65%)
Hmean 4 1591.81 ( 0.00%) 1628.08 ( 2.28%)
Hmean 8 1845.04 ( 0.00%) 1831.80 ( -0.72%)
Hmean 16 2038.61 ( 0.00%) 2091.44 ( 2.59%)
Hmean 32 2327.19 ( 0.00%) 2430.29 ( 4.43%)
Hmean 64 2570.61 ( 0.00%) 2568.54 ( -0.08%)
Hmean 128 2481.89 ( 0.00%) 2499.28 ( 0.70%)
Stddev 1 14.31 ( 0.00%) 5.35 ( 62.65%)
Stddev 2 21.29 ( 0.00%) 11.09 ( 47.92%)
Stddev 4 7.22 ( 0.00%) 6.80 ( 5.92%)
Stddev 8 26.70 ( 0.00%) 9.41 ( 64.76%)
Stddev 16 22.40 ( 0.00%) 20.01 ( 10.70%)
Stddev 32 45.13 ( 0.00%) 44.74 ( 0.85%)
Stddev 64 93.10 ( 0.00%) 93.18 ( -0.09%)
Stddev 128 184.28 ( 0.00%) 177.85 ( 3.49%)
Note the small increase in throughput for low thread counts but also
note that the standard deviation for each sample during the test run is
lower. The throughput figures for dbench can be misleading so the benchmark
is actually modified to time the latency of the processing of one load
file with many samples taken. The difference in latency is
4.15.0-rc3 4.15.0-rc3
vanilla lessmigrate
Amean 1 21.71 ( 0.00%) 21.47 ( 1.08%)
Amean 2 30.89 ( 0.00%) 29.58 ( 4.26%)
Amean 4 47.54 ( 0.00%) 46.61 ( 1.97%)
Amean 8 82.71 ( 0.00%) 82.81 ( -0.12%)
Amean 16 149.45 ( 0.00%) 145.01 ( 2.97%)
Amean 32 265.49 ( 0.00%) 248.43 ( 6.42%)
Amean 64 463.23 ( 0.00%) 463.55 ( -0.07%)
Amean 128 933.97 ( 0.00%) 935.50 ( -0.16%)
Stddev 1 1.58 ( 0.00%) 1.54 ( 2.26%)
Stddev 2 2.84 ( 0.00%) 2.95 ( -4.15%)
Stddev 4 6.78 ( 0.00%) 6.85 ( -0.99%)
Stddev 8 16.85 ( 0.00%) 16.37 ( 2.85%)
Stddev 16 41.59 ( 0.00%) 41.04 ( 1.32%)
Stddev 32 111.05 ( 0.00%) 105.11 ( 5.35%)
Stddev 64 285.94 ( 0.00%) 288.01 ( -0.72%)
Stddev 128 803.39 ( 0.00%) 809.73 ( -0.79%)
It's a small improvement which is not surprising given that migrations that
migrate to a different node as not that common. However, it is noticeable
in the CPU migration statistics which are reduced by 24%.
There was a query for v1 of this patch about NAS so here are the results
for C-class using MPI for parallelisation on the same machine
nas-mpi
4.15.0-rc3 4.15.0-rc3
vanilla noirq
Time cg.C 24.25 ( 0.00%) 23.17 ( 4.45%)
Time ep.C 8.22 ( 0.00%) 8.29 ( -0.85%)
Time ft.C 22.67 ( 0.00%) 20.34 ( 10.28%)
Time is.C 1.42 ( 0.00%) 1.47 ( -3.52%)
Time lu.C 55.62 ( 0.00%) 54.81 ( 1.46%)
Time mg.C 7.93 ( 0.00%) 7.91 ( 0.25%)
4.15.0-rc3 4.15.0-rc3
vanilla noirq-v1r1
User 3799.96 3748.34
System 672.10 626.15
Elapsed 91.91 79.49
lu.C sees a small gain, ft.C a large gain and ep.C and is.C see small
regressions but in terms of absolute time, the difference is small and
likely within run-to-run variance. System CPU usage is slightly reduced.
schbench from Facebook was also requested. This is a bit of a mixed bag but
it's important to note that this workload should not be heavily impacted
by wakeups from interrupt context.
4.15.0-rc3 4.15.0-rc3
vanilla noirq-v1r1
Lat 50.00th-qrtle-1 41.00 ( 0.00%) 41.00 ( 0.00%)
Lat 75.00th-qrtle-1 42.00 ( 0.00%) 42.00 ( 0.00%)
Lat 90.00th-qrtle-1 43.00 ( 0.00%) 44.00 ( -2.33%)
Lat 95.00th-qrtle-1 44.00 ( 0.00%) 46.00 ( -4.55%)
Lat 99.00th-qrtle-1 57.00 ( 0.00%) 58.00 ( -1.75%)
Lat 99.50th-qrtle-1 59.00 ( 0.00%) 59.00 ( 0.00%)
Lat 99.90th-qrtle-1 67.00 ( 0.00%) 78.00 ( -16.42%)
Lat 50.00th-qrtle-2 40.00 ( 0.00%) 51.00 ( -27.50%)
Lat 75.00th-qrtle-2 45.00 ( 0.00%) 56.00 ( -24.44%)
Lat 90.00th-qrtle-2 53.00 ( 0.00%) 59.00 ( -11.32%)
Lat 95.00th-qrtle-2 57.00 ( 0.00%) 61.00 ( -7.02%)
Lat 99.00th-qrtle-2 67.00 ( 0.00%) 71.00 ( -5.97%)
Lat 99.50th-qrtle-2 69.00 ( 0.00%) 74.00 ( -7.25%)
Lat 99.90th-qrtle-2 83.00 ( 0.00%) 77.00 ( 7.23%)
Lat 50.00th-qrtle-4 51.00 ( 0.00%) 51.00 ( 0.00%)
Lat 75.00th-qrtle-4 57.00 ( 0.00%) 56.00 ( 1.75%)
Lat 90.00th-qrtle-4 60.00 ( 0.00%) 59.00 ( 1.67%)
Lat 95.00th-qrtle-4 62.00 ( 0.00%) 62.00 ( 0.00%)
Lat 99.00th-qrtle-4 73.00 ( 0.00%) 72.00 ( 1.37%)
Lat 99.50th-qrtle-4 76.00 ( 0.00%) 74.00 ( 2.63%)
Lat 99.90th-qrtle-4 85.00 ( 0.00%) 78.00 ( 8.24%)
Lat 50.00th-qrtle-8 54.00 ( 0.00%) 58.00 ( -7.41%)
Lat 75.00th-qrtle-8 59.00 ( 0.00%) 62.00 ( -5.08%)
Lat 90.00th-qrtle-8 65.00 ( 0.00%) 66.00 ( -1.54%)
Lat 95.00th-qrtle-8 67.00 ( 0.00%) 70.00 ( -4.48%)
Lat 99.00th-qrtle-8 78.00 ( 0.00%) 79.00 ( -1.28%)
Lat 99.50th-qrtle-8 81.00 ( 0.00%) 80.00 ( 1.23%)
Lat 99.90th-qrtle-8 116.00 ( 0.00%) 83.00 ( 28.45%)
Lat 50.00th-qrtle-16 65.00 ( 0.00%) 64.00 ( 1.54%)
Lat 75.00th-qrtle-16 77.00 ( 0.00%) 71.00 ( 7.79%)
Lat 90.00th-qrtle-16 83.00 ( 0.00%) 82.00 ( 1.20%)
Lat 95.00th-qrtle-16 87.00 ( 0.00%) 87.00 ( 0.00%)
Lat 99.00th-qrtle-16 95.00 ( 0.00%) 96.00 ( -1.05%)
Lat 99.50th-qrtle-16 99.00 ( 0.00%) 103.00 ( -4.04%)
Lat 99.90th-qrtle-16 104.00 ( 0.00%) 122.00 ( -17.31%)
Lat 50.00th-qrtle-32 71.00 ( 0.00%) 73.00 ( -2.82%)
Lat 75.00th-qrtle-32 91.00 ( 0.00%) 92.00 ( -1.10%)
Lat 90.00th-qrtle-32 108.00 ( 0.00%) 107.00 ( 0.93%)
Lat 95.00th-qrtle-32 118.00 ( 0.00%) 115.00 ( 2.54%)
Lat 99.00th-qrtle-32 134.00 ( 0.00%) 129.00 ( 3.73%)
Lat 99.50th-qrtle-32 138.00 ( 0.00%) 133.00 ( 3.62%)
Lat 99.90th-qrtle-32 149.00 ( 0.00%) 146.00 ( 2.01%)
Lat 50.00th-qrtle-39 83.00 ( 0.00%) 81.00 ( 2.41%)
Lat 75.00th-qrtle-39 105.00 ( 0.00%) 102.00 ( 2.86%)
Lat 90.00th-qrtle-39 120.00 ( 0.00%) 119.00 ( 0.83%)
Lat 95.00th-qrtle-39 129.00 ( 0.00%) 128.00 ( 0.78%)
Lat 99.00th-qrtle-39 153.00 ( 0.00%) 149.00 ( 2.61%)
Lat 99.50th-qrtle-39 166.00 ( 0.00%) 156.00 ( 6.02%)
Lat 99.90th-qrtle-39 12304.00 ( 0.00%) 12848.00 ( -4.42%)
When heavily loaded (e.g. 99.50th-qrtle-39 indicates 39 threads), there
are small gains in many cases. Otherwise it depends on the quartile used
where it can be bad -- e.g. 75.00th-qrtle-2. However, even these results
are probably a co-incidence. For this workload, much depends on what node
the threads get placed on and their relative locality and not wakeups from
interrupt context. A larger component on how it behaves would be automatic
NUMA balancing where a fault incurred to measure locality would be a much
larger contributer to latency than the wakeup path.
This is the results from an almost identical machine that happened to run
the same test. They only differ in terms of storage which is irrelevant
for this test.
4.15.0-rc3 4.15.0-rc3
vanilla noirq-v1r1
Lat 50.00th-qrtle-1 41.00 ( 0.00%) 41.00 ( 0.00%)
Lat 75.00th-qrtle-1 42.00 ( 0.00%) 42.00 ( 0.00%)
Lat 90.00th-qrtle-1 44.00 ( 0.00%) 43.00 ( 2.27%)
Lat 95.00th-qrtle-1 53.00 ( 0.00%) 45.00 ( 15.09%)
Lat 99.00th-qrtle-1 59.00 ( 0.00%) 58.00 ( 1.69%)
Lat 99.50th-qrtle-1 60.00 ( 0.00%) 59.00 ( 1.67%)
Lat 99.90th-qrtle-1 86.00 ( 0.00%) 61.00 ( 29.07%)
Lat 50.00th-qrtle-2 52.00 ( 0.00%) 41.00 ( 21.15%)
Lat 75.00th-qrtle-2 57.00 ( 0.00%) 46.00 ( 19.30%)
Lat 90.00th-qrtle-2 60.00 ( 0.00%) 53.00 ( 11.67%)
Lat 95.00th-qrtle-2 62.00 ( 0.00%) 57.00 ( 8.06%)
Lat 99.00th-qrtle-2 73.00 ( 0.00%) 68.00 ( 6.85%)
Lat 99.50th-qrtle-2 74.00 ( 0.00%) 71.00 ( 4.05%)
Lat 99.90th-qrtle-2 90.00 ( 0.00%) 75.00 ( 16.67%)
Lat 50.00th-qrtle-4 57.00 ( 0.00%) 52.00 ( 8.77%)
Lat 75.00th-qrtle-4 60.00 ( 0.00%) 58.00 ( 3.33%)
Lat 90.00th-qrtle-4 62.00 ( 0.00%) 62.00 ( 0.00%)
Lat 95.00th-qrtle-4 65.00 ( 0.00%) 65.00 ( 0.00%)
Lat 99.00th-qrtle-4 76.00 ( 0.00%) 75.00 ( 1.32%)
Lat 99.50th-qrtle-4 77.00 ( 0.00%) 77.00 ( 0.00%)
Lat 99.90th-qrtle-4 87.00 ( 0.00%) 81.00 ( 6.90%)
Lat 50.00th-qrtle-8 59.00 ( 0.00%) 57.00 ( 3.39%)
Lat 75.00th-qrtle-8 63.00 ( 0.00%) 62.00 ( 1.59%)
Lat 90.00th-qrtle-8 66.00 ( 0.00%) 67.00 ( -1.52%)
Lat 95.00th-qrtle-8 68.00 ( 0.00%) 70.00 ( -2.94%)
Lat 99.00th-qrtle-8 79.00 ( 0.00%) 80.00 ( -1.27%)
Lat 99.50th-qrtle-8 80.00 ( 0.00%) 84.00 ( -5.00%)
Lat 99.90th-qrtle-8 84.00 ( 0.00%) 90.00 ( -7.14%)
Lat 50.00th-qrtle-16 65.00 ( 0.00%) 65.00 ( 0.00%)
Lat 75.00th-qrtle-16 77.00 ( 0.00%) 75.00 ( 2.60%)
Lat 90.00th-qrtle-16 84.00 ( 0.00%) 83.00 ( 1.19%)
Lat 95.00th-qrtle-16 88.00 ( 0.00%) 87.00 ( 1.14%)
Lat 99.00th-qrtle-16 97.00 ( 0.00%) 96.00 ( 1.03%)
Lat 99.50th-qrtle-16 100.00 ( 0.00%) 104.00 ( -4.00%)
Lat 99.90th-qrtle-16 110.00 ( 0.00%) 126.00 ( -14.55%)
Lat 50.00th-qrtle-32 70.00 ( 0.00%) 71.00 ( -1.43%)
Lat 75.00th-qrtle-32 92.00 ( 0.00%) 94.00 ( -2.17%)
Lat 90.00th-qrtle-32 110.00 ( 0.00%) 110.00 ( 0.00%)
Lat 95.00th-qrtle-32 121.00 ( 0.00%) 118.00 ( 2.48%)
Lat 99.00th-qrtle-32 135.00 ( 0.00%) 137.00 ( -1.48%)
Lat 99.50th-qrtle-32 140.00 ( 0.00%) 146.00 ( -4.29%)
Lat 99.90th-qrtle-32 150.00 ( 0.00%) 160.00 ( -6.67%)
Lat 50.00th-qrtle-39 80.00 ( 0.00%) 71.00 ( 11.25%)
Lat 75.00th-qrtle-39 102.00 ( 0.00%) 91.00 ( 10.78%)
Lat 90.00th-qrtle-39 118.00 ( 0.00%) 108.00 ( 8.47%)
Lat 95.00th-qrtle-39 128.00 ( 0.00%) 117.00 ( 8.59%)
Lat 99.00th-qrtle-39 149.00 ( 0.00%) 133.00 ( 10.74%)
Lat 99.50th-qrtle-39 160.00 ( 0.00%) 139.00 ( 13.12%)
Lat 99.90th-qrtle-39 13808.00 ( 0.00%) 4920.00 ( 64.37%)
Despite being nearly identical, it showed a variety of major gains so
I'm not convinced that heavy emphasis should be placed on this particular
workload in terms of evaluating this particular patch. Further evidence of
this is the fact that testing on a UMA machine showed small gains/losses
even though the patch should be a no-op on UMA.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20171219085947.13136-2-mgorman@techsingularity.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-19 08:59:47 +00:00
|
|
|
/*
|
|
|
|
* If this_cpu is idle, it implies the wakeup is from interrupt
|
|
|
|
* context. Only allow the move if cache is shared. Otherwise an
|
|
|
|
* interrupt intensive workload could force all tasks onto one
|
|
|
|
* node depending on the IO topology or IRQ affinity settings.
|
2018-01-30 10:45:54 +00:00
|
|
|
*
|
|
|
|
* If the prev_cpu is idle and cache affine then avoid a migration.
|
|
|
|
* There is no guarantee that the cache hot data from an interrupt
|
|
|
|
* is more important than cache hot data on the prev_cpu and from
|
|
|
|
* a cpufreq perspective, it's better to have higher utilisation
|
|
|
|
* on one CPU.
|
sched/fair: Only immediately migrate tasks due to interrupts if prev and target CPUs share cache
If waking from an idle CPU due to an interrupt then it's possible that
the waker task will be pulled to wake on the current CPU. Unfortunately,
depending on the type of interrupt and IRQ configuration, there may not
be a strong relationship between the CPU an interrupt was delivered on
and the CPU a task was running on. For example, the interrupts could all
be delivered to CPUs on one particular node due to the machine topology
or IRQ affinity configuration. Another example is an interrupt for an IO
completion which can be delivered to any CPU where there is no guarantee
the data is either cache hot or even local.
This patch was motivated by the observation that an IO workload was
being pulled cross-node on a frequent basis when IO completed. From a
wakeup latency perspective, it's still useful to know that an idle CPU is
immediately available for use but lets only consider an automatic migration
if the CPUs share cache to limit damage due to NUMA migrations. Migrations
may still occur if wake_affine_weight determines it's appropriate.
These are the throughput results for dbench running on ext4 comparing
4.15-rc3 and this patch on a 2-socket machine where interrupts due to IO
completions can happen on any CPU.
4.15.0-rc3 4.15.0-rc3
vanilla lessmigrate
Hmean 1 854.64 ( 0.00%) 865.01 ( 1.21%)
Hmean 2 1229.60 ( 0.00%) 1274.44 ( 3.65%)
Hmean 4 1591.81 ( 0.00%) 1628.08 ( 2.28%)
Hmean 8 1845.04 ( 0.00%) 1831.80 ( -0.72%)
Hmean 16 2038.61 ( 0.00%) 2091.44 ( 2.59%)
Hmean 32 2327.19 ( 0.00%) 2430.29 ( 4.43%)
Hmean 64 2570.61 ( 0.00%) 2568.54 ( -0.08%)
Hmean 128 2481.89 ( 0.00%) 2499.28 ( 0.70%)
Stddev 1 14.31 ( 0.00%) 5.35 ( 62.65%)
Stddev 2 21.29 ( 0.00%) 11.09 ( 47.92%)
Stddev 4 7.22 ( 0.00%) 6.80 ( 5.92%)
Stddev 8 26.70 ( 0.00%) 9.41 ( 64.76%)
Stddev 16 22.40 ( 0.00%) 20.01 ( 10.70%)
Stddev 32 45.13 ( 0.00%) 44.74 ( 0.85%)
Stddev 64 93.10 ( 0.00%) 93.18 ( -0.09%)
Stddev 128 184.28 ( 0.00%) 177.85 ( 3.49%)
Note the small increase in throughput for low thread counts but also
note that the standard deviation for each sample during the test run is
lower. The throughput figures for dbench can be misleading so the benchmark
is actually modified to time the latency of the processing of one load
file with many samples taken. The difference in latency is
4.15.0-rc3 4.15.0-rc3
vanilla lessmigrate
Amean 1 21.71 ( 0.00%) 21.47 ( 1.08%)
Amean 2 30.89 ( 0.00%) 29.58 ( 4.26%)
Amean 4 47.54 ( 0.00%) 46.61 ( 1.97%)
Amean 8 82.71 ( 0.00%) 82.81 ( -0.12%)
Amean 16 149.45 ( 0.00%) 145.01 ( 2.97%)
Amean 32 265.49 ( 0.00%) 248.43 ( 6.42%)
Amean 64 463.23 ( 0.00%) 463.55 ( -0.07%)
Amean 128 933.97 ( 0.00%) 935.50 ( -0.16%)
Stddev 1 1.58 ( 0.00%) 1.54 ( 2.26%)
Stddev 2 2.84 ( 0.00%) 2.95 ( -4.15%)
Stddev 4 6.78 ( 0.00%) 6.85 ( -0.99%)
Stddev 8 16.85 ( 0.00%) 16.37 ( 2.85%)
Stddev 16 41.59 ( 0.00%) 41.04 ( 1.32%)
Stddev 32 111.05 ( 0.00%) 105.11 ( 5.35%)
Stddev 64 285.94 ( 0.00%) 288.01 ( -0.72%)
Stddev 128 803.39 ( 0.00%) 809.73 ( -0.79%)
It's a small improvement which is not surprising given that migrations that
migrate to a different node as not that common. However, it is noticeable
in the CPU migration statistics which are reduced by 24%.
There was a query for v1 of this patch about NAS so here are the results
for C-class using MPI for parallelisation on the same machine
nas-mpi
4.15.0-rc3 4.15.0-rc3
vanilla noirq
Time cg.C 24.25 ( 0.00%) 23.17 ( 4.45%)
Time ep.C 8.22 ( 0.00%) 8.29 ( -0.85%)
Time ft.C 22.67 ( 0.00%) 20.34 ( 10.28%)
Time is.C 1.42 ( 0.00%) 1.47 ( -3.52%)
Time lu.C 55.62 ( 0.00%) 54.81 ( 1.46%)
Time mg.C 7.93 ( 0.00%) 7.91 ( 0.25%)
4.15.0-rc3 4.15.0-rc3
vanilla noirq-v1r1
User 3799.96 3748.34
System 672.10 626.15
Elapsed 91.91 79.49
lu.C sees a small gain, ft.C a large gain and ep.C and is.C see small
regressions but in terms of absolute time, the difference is small and
likely within run-to-run variance. System CPU usage is slightly reduced.
schbench from Facebook was also requested. This is a bit of a mixed bag but
it's important to note that this workload should not be heavily impacted
by wakeups from interrupt context.
4.15.0-rc3 4.15.0-rc3
vanilla noirq-v1r1
Lat 50.00th-qrtle-1 41.00 ( 0.00%) 41.00 ( 0.00%)
Lat 75.00th-qrtle-1 42.00 ( 0.00%) 42.00 ( 0.00%)
Lat 90.00th-qrtle-1 43.00 ( 0.00%) 44.00 ( -2.33%)
Lat 95.00th-qrtle-1 44.00 ( 0.00%) 46.00 ( -4.55%)
Lat 99.00th-qrtle-1 57.00 ( 0.00%) 58.00 ( -1.75%)
Lat 99.50th-qrtle-1 59.00 ( 0.00%) 59.00 ( 0.00%)
Lat 99.90th-qrtle-1 67.00 ( 0.00%) 78.00 ( -16.42%)
Lat 50.00th-qrtle-2 40.00 ( 0.00%) 51.00 ( -27.50%)
Lat 75.00th-qrtle-2 45.00 ( 0.00%) 56.00 ( -24.44%)
Lat 90.00th-qrtle-2 53.00 ( 0.00%) 59.00 ( -11.32%)
Lat 95.00th-qrtle-2 57.00 ( 0.00%) 61.00 ( -7.02%)
Lat 99.00th-qrtle-2 67.00 ( 0.00%) 71.00 ( -5.97%)
Lat 99.50th-qrtle-2 69.00 ( 0.00%) 74.00 ( -7.25%)
Lat 99.90th-qrtle-2 83.00 ( 0.00%) 77.00 ( 7.23%)
Lat 50.00th-qrtle-4 51.00 ( 0.00%) 51.00 ( 0.00%)
Lat 75.00th-qrtle-4 57.00 ( 0.00%) 56.00 ( 1.75%)
Lat 90.00th-qrtle-4 60.00 ( 0.00%) 59.00 ( 1.67%)
Lat 95.00th-qrtle-4 62.00 ( 0.00%) 62.00 ( 0.00%)
Lat 99.00th-qrtle-4 73.00 ( 0.00%) 72.00 ( 1.37%)
Lat 99.50th-qrtle-4 76.00 ( 0.00%) 74.00 ( 2.63%)
Lat 99.90th-qrtle-4 85.00 ( 0.00%) 78.00 ( 8.24%)
Lat 50.00th-qrtle-8 54.00 ( 0.00%) 58.00 ( -7.41%)
Lat 75.00th-qrtle-8 59.00 ( 0.00%) 62.00 ( -5.08%)
Lat 90.00th-qrtle-8 65.00 ( 0.00%) 66.00 ( -1.54%)
Lat 95.00th-qrtle-8 67.00 ( 0.00%) 70.00 ( -4.48%)
Lat 99.00th-qrtle-8 78.00 ( 0.00%) 79.00 ( -1.28%)
Lat 99.50th-qrtle-8 81.00 ( 0.00%) 80.00 ( 1.23%)
Lat 99.90th-qrtle-8 116.00 ( 0.00%) 83.00 ( 28.45%)
Lat 50.00th-qrtle-16 65.00 ( 0.00%) 64.00 ( 1.54%)
Lat 75.00th-qrtle-16 77.00 ( 0.00%) 71.00 ( 7.79%)
Lat 90.00th-qrtle-16 83.00 ( 0.00%) 82.00 ( 1.20%)
Lat 95.00th-qrtle-16 87.00 ( 0.00%) 87.00 ( 0.00%)
Lat 99.00th-qrtle-16 95.00 ( 0.00%) 96.00 ( -1.05%)
Lat 99.50th-qrtle-16 99.00 ( 0.00%) 103.00 ( -4.04%)
Lat 99.90th-qrtle-16 104.00 ( 0.00%) 122.00 ( -17.31%)
Lat 50.00th-qrtle-32 71.00 ( 0.00%) 73.00 ( -2.82%)
Lat 75.00th-qrtle-32 91.00 ( 0.00%) 92.00 ( -1.10%)
Lat 90.00th-qrtle-32 108.00 ( 0.00%) 107.00 ( 0.93%)
Lat 95.00th-qrtle-32 118.00 ( 0.00%) 115.00 ( 2.54%)
Lat 99.00th-qrtle-32 134.00 ( 0.00%) 129.00 ( 3.73%)
Lat 99.50th-qrtle-32 138.00 ( 0.00%) 133.00 ( 3.62%)
Lat 99.90th-qrtle-32 149.00 ( 0.00%) 146.00 ( 2.01%)
Lat 50.00th-qrtle-39 83.00 ( 0.00%) 81.00 ( 2.41%)
Lat 75.00th-qrtle-39 105.00 ( 0.00%) 102.00 ( 2.86%)
Lat 90.00th-qrtle-39 120.00 ( 0.00%) 119.00 ( 0.83%)
Lat 95.00th-qrtle-39 129.00 ( 0.00%) 128.00 ( 0.78%)
Lat 99.00th-qrtle-39 153.00 ( 0.00%) 149.00 ( 2.61%)
Lat 99.50th-qrtle-39 166.00 ( 0.00%) 156.00 ( 6.02%)
Lat 99.90th-qrtle-39 12304.00 ( 0.00%) 12848.00 ( -4.42%)
When heavily loaded (e.g. 99.50th-qrtle-39 indicates 39 threads), there
are small gains in many cases. Otherwise it depends on the quartile used
where it can be bad -- e.g. 75.00th-qrtle-2. However, even these results
are probably a co-incidence. For this workload, much depends on what node
the threads get placed on and their relative locality and not wakeups from
interrupt context. A larger component on how it behaves would be automatic
NUMA balancing where a fault incurred to measure locality would be a much
larger contributer to latency than the wakeup path.
This is the results from an almost identical machine that happened to run
the same test. They only differ in terms of storage which is irrelevant
for this test.
4.15.0-rc3 4.15.0-rc3
vanilla noirq-v1r1
Lat 50.00th-qrtle-1 41.00 ( 0.00%) 41.00 ( 0.00%)
Lat 75.00th-qrtle-1 42.00 ( 0.00%) 42.00 ( 0.00%)
Lat 90.00th-qrtle-1 44.00 ( 0.00%) 43.00 ( 2.27%)
Lat 95.00th-qrtle-1 53.00 ( 0.00%) 45.00 ( 15.09%)
Lat 99.00th-qrtle-1 59.00 ( 0.00%) 58.00 ( 1.69%)
Lat 99.50th-qrtle-1 60.00 ( 0.00%) 59.00 ( 1.67%)
Lat 99.90th-qrtle-1 86.00 ( 0.00%) 61.00 ( 29.07%)
Lat 50.00th-qrtle-2 52.00 ( 0.00%) 41.00 ( 21.15%)
Lat 75.00th-qrtle-2 57.00 ( 0.00%) 46.00 ( 19.30%)
Lat 90.00th-qrtle-2 60.00 ( 0.00%) 53.00 ( 11.67%)
Lat 95.00th-qrtle-2 62.00 ( 0.00%) 57.00 ( 8.06%)
Lat 99.00th-qrtle-2 73.00 ( 0.00%) 68.00 ( 6.85%)
Lat 99.50th-qrtle-2 74.00 ( 0.00%) 71.00 ( 4.05%)
Lat 99.90th-qrtle-2 90.00 ( 0.00%) 75.00 ( 16.67%)
Lat 50.00th-qrtle-4 57.00 ( 0.00%) 52.00 ( 8.77%)
Lat 75.00th-qrtle-4 60.00 ( 0.00%) 58.00 ( 3.33%)
Lat 90.00th-qrtle-4 62.00 ( 0.00%) 62.00 ( 0.00%)
Lat 95.00th-qrtle-4 65.00 ( 0.00%) 65.00 ( 0.00%)
Lat 99.00th-qrtle-4 76.00 ( 0.00%) 75.00 ( 1.32%)
Lat 99.50th-qrtle-4 77.00 ( 0.00%) 77.00 ( 0.00%)
Lat 99.90th-qrtle-4 87.00 ( 0.00%) 81.00 ( 6.90%)
Lat 50.00th-qrtle-8 59.00 ( 0.00%) 57.00 ( 3.39%)
Lat 75.00th-qrtle-8 63.00 ( 0.00%) 62.00 ( 1.59%)
Lat 90.00th-qrtle-8 66.00 ( 0.00%) 67.00 ( -1.52%)
Lat 95.00th-qrtle-8 68.00 ( 0.00%) 70.00 ( -2.94%)
Lat 99.00th-qrtle-8 79.00 ( 0.00%) 80.00 ( -1.27%)
Lat 99.50th-qrtle-8 80.00 ( 0.00%) 84.00 ( -5.00%)
Lat 99.90th-qrtle-8 84.00 ( 0.00%) 90.00 ( -7.14%)
Lat 50.00th-qrtle-16 65.00 ( 0.00%) 65.00 ( 0.00%)
Lat 75.00th-qrtle-16 77.00 ( 0.00%) 75.00 ( 2.60%)
Lat 90.00th-qrtle-16 84.00 ( 0.00%) 83.00 ( 1.19%)
Lat 95.00th-qrtle-16 88.00 ( 0.00%) 87.00 ( 1.14%)
Lat 99.00th-qrtle-16 97.00 ( 0.00%) 96.00 ( 1.03%)
Lat 99.50th-qrtle-16 100.00 ( 0.00%) 104.00 ( -4.00%)
Lat 99.90th-qrtle-16 110.00 ( 0.00%) 126.00 ( -14.55%)
Lat 50.00th-qrtle-32 70.00 ( 0.00%) 71.00 ( -1.43%)
Lat 75.00th-qrtle-32 92.00 ( 0.00%) 94.00 ( -2.17%)
Lat 90.00th-qrtle-32 110.00 ( 0.00%) 110.00 ( 0.00%)
Lat 95.00th-qrtle-32 121.00 ( 0.00%) 118.00 ( 2.48%)
Lat 99.00th-qrtle-32 135.00 ( 0.00%) 137.00 ( -1.48%)
Lat 99.50th-qrtle-32 140.00 ( 0.00%) 146.00 ( -4.29%)
Lat 99.90th-qrtle-32 150.00 ( 0.00%) 160.00 ( -6.67%)
Lat 50.00th-qrtle-39 80.00 ( 0.00%) 71.00 ( 11.25%)
Lat 75.00th-qrtle-39 102.00 ( 0.00%) 91.00 ( 10.78%)
Lat 90.00th-qrtle-39 118.00 ( 0.00%) 108.00 ( 8.47%)
Lat 95.00th-qrtle-39 128.00 ( 0.00%) 117.00 ( 8.59%)
Lat 99.00th-qrtle-39 149.00 ( 0.00%) 133.00 ( 10.74%)
Lat 99.50th-qrtle-39 160.00 ( 0.00%) 139.00 ( 13.12%)
Lat 99.90th-qrtle-39 13808.00 ( 0.00%) 4920.00 ( 64.37%)
Despite being nearly identical, it showed a variety of major gains so
I'm not convinced that heavy emphasis should be placed on this particular
workload in terms of evaluating this particular patch. Further evidence of
this is the fact that testing on a UMA machine showed small gains/losses
even though the patch should be a no-op on UMA.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20171219085947.13136-2-mgorman@techsingularity.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-12-19 08:59:47 +00:00
|
|
|
*/
|
2018-05-09 16:39:48 +00:00
|
|
|
if (available_idle_cpu(this_cpu) && cpus_share_cache(this_cpu, prev_cpu))
|
|
|
|
return available_idle_cpu(prev_cpu) ? prev_cpu : this_cpu;
|
2017-07-31 15:50:05 +00:00
|
|
|
|
2017-09-27 09:35:30 +00:00
|
|
|
if (sync && cpu_rq(this_cpu)->nr_running == 1)
|
2018-01-30 10:45:53 +00:00
|
|
|
return this_cpu;
|
2017-07-31 15:50:05 +00:00
|
|
|
|
2018-01-30 10:45:53 +00:00
|
|
|
return nr_cpumask_bits;
|
2017-07-31 15:50:05 +00:00
|
|
|
}
|
|
|
|
|
2018-01-30 10:45:53 +00:00
|
|
|
static int
|
2017-10-06 07:23:24 +00:00
|
|
|
wake_affine_weight(struct sched_domain *sd, struct task_struct *p,
|
|
|
|
int this_cpu, int prev_cpu, int sync)
|
2017-07-31 15:50:05 +00:00
|
|
|
{
|
|
|
|
s64 this_eff_load, prev_eff_load;
|
|
|
|
unsigned long task_load;
|
|
|
|
|
2019-10-18 13:26:36 +00:00
|
|
|
this_eff_load = cpu_load(cpu_rq(this_cpu));
|
2017-07-31 15:50:05 +00:00
|
|
|
|
|
|
|
if (sync) {
|
|
|
|
unsigned long current_load = task_h_load(current);
|
|
|
|
|
2017-10-06 07:23:24 +00:00
|
|
|
if (current_load > this_eff_load)
|
2018-01-30 10:45:53 +00:00
|
|
|
return this_cpu;
|
2017-07-31 15:50:05 +00:00
|
|
|
|
2017-10-06 07:23:24 +00:00
|
|
|
this_eff_load -= current_load;
|
2017-07-31 15:50:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
task_load = task_h_load(p);
|
|
|
|
|
2017-10-06 07:23:24 +00:00
|
|
|
this_eff_load += task_load;
|
|
|
|
if (sched_feat(WA_BIAS))
|
|
|
|
this_eff_load *= 100;
|
|
|
|
this_eff_load *= capacity_of(prev_cpu);
|
2017-07-31 15:50:05 +00:00
|
|
|
|
2019-10-18 13:26:36 +00:00
|
|
|
prev_eff_load = cpu_load(cpu_rq(prev_cpu));
|
2017-10-06 07:23:24 +00:00
|
|
|
prev_eff_load -= task_load;
|
|
|
|
if (sched_feat(WA_BIAS))
|
|
|
|
prev_eff_load *= 100 + (sd->imbalance_pct - 100) / 2;
|
|
|
|
prev_eff_load *= capacity_of(this_cpu);
|
2017-07-31 15:50:05 +00:00
|
|
|
|
sched/fair: Do not migrate on wake_affine_weight() if weights are equal
wake_affine_weight() will consider migrating a task to, or near, the current
CPU if there is a load imbalance. If the CPUs share LLC then either CPU
is valid as a search-for-idle-sibling target and equally appropriate for
stacking two tasks on one CPU if an idle sibling is unavailable. If they do
not share cache then a cross-node migration potentially impacts locality
so while they are equal from a CPU capacity point of view, they are not
equal in terms of memory locality. In either case, it's more appropriate
to migrate only if there is a difference in their effective load.
This patch modifies wake_affine_weight() to only consider migrating a task
if there is a load imbalance for normal wakeups but will allow potential
stacking if the loads are equal and it's a sync wakeup.
For the most part, the different in performance is marginal. For example,
on a 4-socket server running netperf UDP_STREAM on localhost the differences
are as follows:
4.15.0 4.15.0
16rc0 noequal-v1r23
Hmean send-64 355.47 ( 0.00%) 349.50 ( -1.68%)
Hmean send-128 697.98 ( 0.00%) 693.35 ( -0.66%)
Hmean send-256 1328.02 ( 0.00%) 1318.77 ( -0.70%)
Hmean send-1024 5051.83 ( 0.00%) 5051.11 ( -0.01%)
Hmean send-2048 9637.02 ( 0.00%) 9601.34 ( -0.37%)
Hmean send-3312 14355.37 ( 0.00%) 14414.51 ( 0.41%)
Hmean send-4096 16464.97 ( 0.00%) 16301.37 ( -0.99%)
Hmean send-8192 26722.42 ( 0.00%) 26428.95 ( -1.10%)
Hmean send-16384 38137.81 ( 0.00%) 38046.11 ( -0.24%)
Hmean recv-64 355.47 ( 0.00%) 349.50 ( -1.68%)
Hmean recv-128 697.98 ( 0.00%) 693.35 ( -0.66%)
Hmean recv-256 1328.02 ( 0.00%) 1318.77 ( -0.70%)
Hmean recv-1024 5051.83 ( 0.00%) 5051.11 ( -0.01%)
Hmean recv-2048 9636.95 ( 0.00%) 9601.30 ( -0.37%)
Hmean recv-3312 14355.32 ( 0.00%) 14414.48 ( 0.41%)
Hmean recv-4096 16464.74 ( 0.00%) 16301.16 ( -0.99%)
Hmean recv-8192 26721.63 ( 0.00%) 26428.17 ( -1.10%)
Hmean recv-16384 38136.00 ( 0.00%) 38044.88 ( -0.24%)
Stddev send-64 7.30 ( 0.00%) 4.75 ( 34.96%)
Stddev send-128 15.15 ( 0.00%) 22.38 ( -47.66%)
Stddev send-256 13.99 ( 0.00%) 19.14 ( -36.81%)
Stddev send-1024 105.73 ( 0.00%) 67.38 ( 36.27%)
Stddev send-2048 294.57 ( 0.00%) 223.88 ( 24.00%)
Stddev send-3312 302.28 ( 0.00%) 271.74 ( 10.10%)
Stddev send-4096 195.92 ( 0.00%) 121.10 ( 38.19%)
Stddev send-8192 399.71 ( 0.00%) 563.77 ( -41.04%)
Stddev send-16384 1163.47 ( 0.00%) 1103.68 ( 5.14%)
Stddev recv-64 7.30 ( 0.00%) 4.75 ( 34.96%)
Stddev recv-128 15.15 ( 0.00%) 22.38 ( -47.66%)
Stddev recv-256 13.99 ( 0.00%) 19.14 ( -36.81%)
Stddev recv-1024 105.73 ( 0.00%) 67.38 ( 36.27%)
Stddev recv-2048 294.59 ( 0.00%) 223.89 ( 24.00%)
Stddev recv-3312 302.24 ( 0.00%) 271.75 ( 10.09%)
Stddev recv-4096 196.03 ( 0.00%) 121.14 ( 38.20%)
Stddev recv-8192 399.86 ( 0.00%) 563.65 ( -40.96%)
Stddev recv-16384 1163.79 ( 0.00%) 1103.86 ( 5.15%)
The difference in overall performance is marginal but note that most
measurements are less variable. There were similar observations for other
netperf comparisons. hackbench with sockets or threads with processes or
threads showed minor difference with some reduction of migration. tbench
showed only marginal differences that were within the noise. dbench,
regardless of filesystem, showed minor differences all of which are
within noise. Multiple machines, both UMA and NUMA were tested without
any regressions showing up.
The biggest risk with a patch like this is affecting wakeup latencies.
However, the schbench load from Facebook which is very sensitive to wakeup
latency showed a mixed result with mostly improvements in wakeup latency:
4.15.0 4.15.0
16rc0 noequal-v1r23
Lat 50.00th-qrtle-1 38.00 ( 0.00%) 38.00 ( 0.00%)
Lat 75.00th-qrtle-1 49.00 ( 0.00%) 41.00 ( 16.33%)
Lat 90.00th-qrtle-1 52.00 ( 0.00%) 50.00 ( 3.85%)
Lat 95.00th-qrtle-1 54.00 ( 0.00%) 51.00 ( 5.56%)
Lat 99.00th-qrtle-1 63.00 ( 0.00%) 60.00 ( 4.76%)
Lat 99.50th-qrtle-1 66.00 ( 0.00%) 61.00 ( 7.58%)
Lat 99.90th-qrtle-1 78.00 ( 0.00%) 65.00 ( 16.67%)
Lat 50.00th-qrtle-2 38.00 ( 0.00%) 38.00 ( 0.00%)
Lat 75.00th-qrtle-2 42.00 ( 0.00%) 43.00 ( -2.38%)
Lat 90.00th-qrtle-2 46.00 ( 0.00%) 48.00 ( -4.35%)
Lat 95.00th-qrtle-2 49.00 ( 0.00%) 50.00 ( -2.04%)
Lat 99.00th-qrtle-2 55.00 ( 0.00%) 57.00 ( -3.64%)
Lat 99.50th-qrtle-2 58.00 ( 0.00%) 60.00 ( -3.45%)
Lat 99.90th-qrtle-2 65.00 ( 0.00%) 68.00 ( -4.62%)
Lat 50.00th-qrtle-4 41.00 ( 0.00%) 41.00 ( 0.00%)
Lat 75.00th-qrtle-4 45.00 ( 0.00%) 46.00 ( -2.22%)
Lat 90.00th-qrtle-4 50.00 ( 0.00%) 50.00 ( 0.00%)
Lat 95.00th-qrtle-4 54.00 ( 0.00%) 53.00 ( 1.85%)
Lat 99.00th-qrtle-4 61.00 ( 0.00%) 61.00 ( 0.00%)
Lat 99.50th-qrtle-4 65.00 ( 0.00%) 64.00 ( 1.54%)
Lat 99.90th-qrtle-4 76.00 ( 0.00%) 82.00 ( -7.89%)
Lat 50.00th-qrtle-8 48.00 ( 0.00%) 46.00 ( 4.17%)
Lat 75.00th-qrtle-8 55.00 ( 0.00%) 54.00 ( 1.82%)
Lat 90.00th-qrtle-8 60.00 ( 0.00%) 59.00 ( 1.67%)
Lat 95.00th-qrtle-8 63.00 ( 0.00%) 63.00 ( 0.00%)
Lat 99.00th-qrtle-8 71.00 ( 0.00%) 69.00 ( 2.82%)
Lat 99.50th-qrtle-8 74.00 ( 0.00%) 73.00 ( 1.35%)
Lat 99.90th-qrtle-8 98.00 ( 0.00%) 90.00 ( 8.16%)
Lat 50.00th-qrtle-16 56.00 ( 0.00%) 55.00 ( 1.79%)
Lat 75.00th-qrtle-16 68.00 ( 0.00%) 67.00 ( 1.47%)
Lat 90.00th-qrtle-16 77.00 ( 0.00%) 78.00 ( -1.30%)
Lat 95.00th-qrtle-16 82.00 ( 0.00%) 84.00 ( -2.44%)
Lat 99.00th-qrtle-16 90.00 ( 0.00%) 93.00 ( -3.33%)
Lat 99.50th-qrtle-16 93.00 ( 0.00%) 97.00 ( -4.30%)
Lat 99.90th-qrtle-16 110.00 ( 0.00%) 110.00 ( 0.00%)
Lat 50.00th-qrtle-32 68.00 ( 0.00%) 62.00 ( 8.82%)
Lat 75.00th-qrtle-32 90.00 ( 0.00%) 83.00 ( 7.78%)
Lat 90.00th-qrtle-32 110.00 ( 0.00%) 100.00 ( 9.09%)
Lat 95.00th-qrtle-32 122.00 ( 0.00%) 111.00 ( 9.02%)
Lat 99.00th-qrtle-32 145.00 ( 0.00%) 133.00 ( 8.28%)
Lat 99.50th-qrtle-32 154.00 ( 0.00%) 143.00 ( 7.14%)
Lat 99.90th-qrtle-32 2316.00 ( 0.00%) 515.00 ( 77.76%)
Lat 50.00th-qrtle-35 69.00 ( 0.00%) 72.00 ( -4.35%)
Lat 75.00th-qrtle-35 92.00 ( 0.00%) 95.00 ( -3.26%)
Lat 90.00th-qrtle-35 111.00 ( 0.00%) 114.00 ( -2.70%)
Lat 95.00th-qrtle-35 122.00 ( 0.00%) 124.00 ( -1.64%)
Lat 99.00th-qrtle-35 142.00 ( 0.00%) 144.00 ( -1.41%)
Lat 99.50th-qrtle-35 150.00 ( 0.00%) 154.00 ( -2.67%)
Lat 99.90th-qrtle-35 6104.00 ( 0.00%) 5640.00 ( 7.60%)
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Giovanni Gherdovich <ggherdovich@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180213133730.24064-4-mgorman@techsingularity.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-02-13 13:37:27 +00:00
|
|
|
/*
|
|
|
|
* If sync, adjust the weight of prev_eff_load such that if
|
|
|
|
* prev_eff == this_eff that select_idle_sibling() will consider
|
|
|
|
* stacking the wakee on top of the waker if no other CPU is
|
|
|
|
* idle.
|
|
|
|
*/
|
|
|
|
if (sync)
|
|
|
|
prev_eff_load += 1;
|
|
|
|
|
|
|
|
return this_eff_load < prev_eff_load ? this_cpu : nr_cpumask_bits;
|
2017-07-31 15:50:05 +00:00
|
|
|
}
|
|
|
|
|
2016-06-22 17:03:13 +00:00
|
|
|
static int wake_affine(struct sched_domain *sd, struct task_struct *p,
|
2018-02-13 13:37:25 +00:00
|
|
|
int this_cpu, int prev_cpu, int sync)
|
2008-03-16 19:36:10 +00:00
|
|
|
{
|
2018-01-30 10:45:53 +00:00
|
|
|
int target = nr_cpumask_bits;
|
2008-03-16 19:36:10 +00:00
|
|
|
|
2018-01-30 10:45:52 +00:00
|
|
|
if (sched_feat(WA_IDLE))
|
2018-01-30 10:45:53 +00:00
|
|
|
target = wake_affine_idle(this_cpu, prev_cpu, sync);
|
2017-07-31 15:50:05 +00:00
|
|
|
|
2018-01-30 10:45:53 +00:00
|
|
|
if (sched_feat(WA_WEIGHT) && target == nr_cpumask_bits)
|
|
|
|
target = wake_affine_weight(sd, p, this_cpu, prev_cpu, sync);
|
2008-03-16 19:36:10 +00:00
|
|
|
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(p->se.statistics.nr_wakeups_affine_attempts);
|
2018-01-30 10:45:53 +00:00
|
|
|
if (target == nr_cpumask_bits)
|
|
|
|
return prev_cpu;
|
2008-03-16 19:36:10 +00:00
|
|
|
|
2018-01-30 10:45:53 +00:00
|
|
|
schedstat_inc(sd->ttwu_move_affine);
|
|
|
|
schedstat_inc(p->se.statistics.nr_wakeups_affine);
|
|
|
|
return target;
|
2008-03-16 19:36:10 +00:00
|
|
|
}
|
|
|
|
|
2009-09-10 11:36:25 +00:00
|
|
|
static struct sched_group *
|
2009-09-03 11:16:51 +00:00
|
|
|
find_idlest_group(struct sched_domain *sd, struct task_struct *p,
|
2019-10-18 13:26:38 +00:00
|
|
|
int this_cpu, int sd_flag);
|
2009-09-10 11:36:25 +00:00
|
|
|
|
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* find_idlest_group_cpu - find the idlest CPU among the CPUs in the group.
|
2009-09-10 11:36:25 +00:00
|
|
|
*/
|
|
|
|
static int
|
2017-10-05 11:45:12 +00:00
|
|
|
find_idlest_group_cpu(struct sched_group *group, struct task_struct *p, int this_cpu)
|
2009-09-10 11:36:25 +00:00
|
|
|
{
|
|
|
|
unsigned long load, min_load = ULONG_MAX;
|
2014-09-04 15:32:10 +00:00
|
|
|
unsigned int min_exit_latency = UINT_MAX;
|
|
|
|
u64 latest_idle_timestamp = 0;
|
|
|
|
int least_loaded_cpu = this_cpu;
|
2019-11-14 10:49:27 +00:00
|
|
|
int shallowest_idle_cpu = -1;
|
2009-09-10 11:36:25 +00:00
|
|
|
int i;
|
|
|
|
|
2016-06-22 17:03:14 +00:00
|
|
|
/* Check if we have any choice: */
|
|
|
|
if (group->group_weight == 1)
|
2017-05-01 09:03:12 +00:00
|
|
|
return cpumask_first(sched_group_span(group));
|
2016-06-22 17:03:14 +00:00
|
|
|
|
2009-09-10 11:36:25 +00:00
|
|
|
/* Traverse only the allowed CPUs */
|
2019-04-23 14:26:36 +00:00
|
|
|
for_each_cpu_and(i, sched_group_span(group), p->cpus_ptr) {
|
2019-11-14 10:49:27 +00:00
|
|
|
if (sched_idle_cpu(i))
|
|
|
|
return i;
|
|
|
|
|
2018-05-09 16:39:48 +00:00
|
|
|
if (available_idle_cpu(i)) {
|
2014-09-04 15:32:10 +00:00
|
|
|
struct rq *rq = cpu_rq(i);
|
|
|
|
struct cpuidle_state *idle = idle_get_state(rq);
|
|
|
|
if (idle && idle->exit_latency < min_exit_latency) {
|
|
|
|
/*
|
|
|
|
* We give priority to a CPU whose idle state
|
|
|
|
* has the smallest exit latency irrespective
|
|
|
|
* of any idle timestamp.
|
|
|
|
*/
|
|
|
|
min_exit_latency = idle->exit_latency;
|
|
|
|
latest_idle_timestamp = rq->idle_stamp;
|
|
|
|
shallowest_idle_cpu = i;
|
|
|
|
} else if ((!idle || idle->exit_latency == min_exit_latency) &&
|
|
|
|
rq->idle_stamp > latest_idle_timestamp) {
|
|
|
|
/*
|
|
|
|
* If equal or no active idle state, then
|
|
|
|
* the most recently idled CPU might have
|
|
|
|
* a warmer cache.
|
|
|
|
*/
|
|
|
|
latest_idle_timestamp = rq->idle_stamp;
|
|
|
|
shallowest_idle_cpu = i;
|
|
|
|
}
|
2019-11-14 10:49:27 +00:00
|
|
|
} else if (shallowest_idle_cpu == -1) {
|
2019-10-18 13:26:36 +00:00
|
|
|
load = cpu_load(cpu_rq(i));
|
2017-12-15 15:39:44 +00:00
|
|
|
if (load < min_load) {
|
2014-09-04 15:32:10 +00:00
|
|
|
min_load = load;
|
|
|
|
least_loaded_cpu = i;
|
|
|
|
}
|
2008-01-25 20:08:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-14 10:49:27 +00:00
|
|
|
return shallowest_idle_cpu != -1 ? shallowest_idle_cpu : least_loaded_cpu;
|
2009-09-10 11:36:25 +00:00
|
|
|
}
|
2008-01-25 20:08:09 +00:00
|
|
|
|
2017-10-05 11:45:12 +00:00
|
|
|
static inline int find_idlest_cpu(struct sched_domain *sd, struct task_struct *p,
|
|
|
|
int cpu, int prev_cpu, int sd_flag)
|
|
|
|
{
|
2017-10-05 11:45:16 +00:00
|
|
|
int new_cpu = cpu;
|
2017-10-05 11:45:12 +00:00
|
|
|
|
2019-04-23 14:26:36 +00:00
|
|
|
if (!cpumask_intersects(sched_domain_span(sd), p->cpus_ptr))
|
2017-10-05 11:45:15 +00:00
|
|
|
return prev_cpu;
|
|
|
|
|
2018-04-26 10:30:51 +00:00
|
|
|
/*
|
2019-10-18 13:26:38 +00:00
|
|
|
* We need task's util for cpu_util_without, sync it up to
|
sched/fair: Fix cpu_util_wake() for 'execl' type workloads
A ~10% regression has been reported for UnixBench's execl throughput
test by Aaron Lu and Ye Xiaolong:
https://lkml.org/lkml/2018/10/30/765
That test is pretty simple, it does a "recursive" execve() syscall on the
same binary. Starting from the syscall, this sequence is possible:
do_execve()
do_execveat_common()
__do_execve_file()
sched_exec()
select_task_rq_fair() <==| Task already enqueued
find_idlest_cpu()
find_idlest_group()
capacity_spare_wake() <==| Functions not called from
cpu_util_wake() | the wakeup path
which means we can end up calling cpu_util_wake() not only from the
"wakeup path", as its name would suggest. Indeed, the task doing an
execve() syscall is already enqueued on the CPU we want to get the
cpu_util_wake() for.
The estimated utilization for a CPU computed in cpu_util_wake() was
written under the assumption that function can be called only from the
wakeup path. If instead the task is already enqueued, we end up with a
utilization which does not remove the current task's contribution from
the estimated utilization of the CPU.
This will wrongly assume a reduced spare capacity on the current CPU and
increase the chances to migrate the task on execve.
The regression is tracked down to:
commit d519329f72a6 ("sched/fair: Update util_est only on util_avg updates")
because in that patch we turn on by default the UTIL_EST sched feature.
However, the real issue is introduced by:
commit f9be3e5961c5 ("sched/fair: Use util_est in LB and WU paths")
Let's fix this by ensuring to always discount the task estimated
utilization from the CPU's estimated utilization when the task is also
the current one. The same benchmark of the bug report, executed on a
dual socket 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz machine,
reports these "Execl Throughput" figures (higher the better):
mainline : 48136.5 lps
mainline+fix : 55376.5 lps
which correspond to a 15% speedup.
Moreover, since {cpu_util,capacity_spare}_wake() are not really only
used from the wakeup path, let's remove this ambiguity by using a better
matching name: {cpu_util,capacity_spare}_without().
Since we are at that, let's also improve the existing documentation.
Reported-by: Aaron Lu <aaron.lu@intel.com>
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Perret <quentin.perret@arm.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Fixes: f9be3e5961c5 (sched/fair: Use util_est in LB and WU paths)
Link: https://lore.kernel.org/lkml/20181025093100.GB13236@e110439-lin/
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-11-05 14:53:58 +00:00
|
|
|
* prev_cpu's last_update_time.
|
2018-04-26 10:30:51 +00:00
|
|
|
*/
|
|
|
|
if (!(sd_flag & SD_BALANCE_FORK))
|
|
|
|
sync_entity_load_avg(&p->se);
|
|
|
|
|
2017-10-05 11:45:12 +00:00
|
|
|
while (sd) {
|
|
|
|
struct sched_group *group;
|
|
|
|
struct sched_domain *tmp;
|
|
|
|
int weight;
|
|
|
|
|
|
|
|
if (!(sd->flags & sd_flag)) {
|
|
|
|
sd = sd->child;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
group = find_idlest_group(sd, p, cpu, sd_flag);
|
|
|
|
if (!group) {
|
|
|
|
sd = sd->child;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
new_cpu = find_idlest_group_cpu(group, p, cpu);
|
2017-10-05 11:45:13 +00:00
|
|
|
if (new_cpu == cpu) {
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/* Now try balancing at a lower domain level of 'cpu': */
|
2017-10-05 11:45:12 +00:00
|
|
|
sd = sd->child;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/* Now try balancing at a lower domain level of 'new_cpu': */
|
2017-10-05 11:45:12 +00:00
|
|
|
cpu = new_cpu;
|
|
|
|
weight = sd->span_weight;
|
|
|
|
sd = NULL;
|
|
|
|
for_each_domain(cpu, tmp) {
|
|
|
|
if (weight <= tmp->span_weight)
|
|
|
|
break;
|
|
|
|
if (tmp->flags & sd_flag)
|
|
|
|
sd = tmp;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return new_cpu;
|
|
|
|
}
|
|
|
|
|
2016-05-09 08:38:05 +00:00
|
|
|
#ifdef CONFIG_SCHED_SMT
|
2018-05-29 14:43:46 +00:00
|
|
|
DEFINE_STATIC_KEY_FALSE(sched_smt_present);
|
cpu/hotplug: Fix "SMT disabled by BIOS" detection for KVM
With the following commit:
73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS")
... the hotplug code attempted to detect when SMT was disabled by BIOS,
in which case it reported SMT as permanently disabled. However, that
code broke a virt hotplug scenario, where the guest is booted with only
primary CPU threads, and a sibling is brought online later.
The problem is that there doesn't seem to be a way to reliably
distinguish between the HW "SMT disabled by BIOS" case and the virt
"sibling not yet brought online" case. So the above-mentioned commit
was a bit misguided, as it permanently disabled SMT for both cases,
preventing future virt sibling hotplugs.
Going back and reviewing the original problems which were attempted to
be solved by that commit, when SMT was disabled in BIOS:
1) /sys/devices/system/cpu/smt/control showed "on" instead of
"notsupported"; and
2) vmx_vm_init() was incorrectly showing the L1TF_MSG_SMT warning.
I'd propose that we instead consider #1 above to not actually be a
problem. Because, at least in the virt case, it's possible that SMT
wasn't disabled by BIOS and a sibling thread could be brought online
later. So it makes sense to just always default the smt control to "on"
to allow for that possibility (assuming cpuid indicates that the CPU
supports SMT).
The real problem is #2, which has a simple fix: change vmx_vm_init() to
query the actual current SMT state -- i.e., whether any siblings are
currently online -- instead of looking at the SMT "control" sysfs value.
So fix it by:
a) reverting the original "fix" and its followup fix:
73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS")
bc2d8d262cba ("cpu/hotplug: Fix SMT supported evaluation")
and
b) changing vmx_vm_init() to query the actual current SMT state --
instead of the sysfs control value -- to determine whether the L1TF
warning is needed. This also requires the 'sched_smt_present'
variable to exported, instead of 'cpu_smt_control'.
Fixes: 73d5e2b47264 ("cpu/hotplug: detect SMT disabled by BIOS")
Reported-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Joe Mario <jmario@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: kvm@vger.kernel.org
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/e3a85d585da28cc333ecbc1e78ee9216e6da9396.1548794349.git.jpoimboe@redhat.com
2019-01-30 13:13:58 +00:00
|
|
|
EXPORT_SYMBOL_GPL(sched_smt_present);
|
2016-05-09 08:38:05 +00:00
|
|
|
|
|
|
|
static inline void set_idle_cores(int cpu, int val)
|
|
|
|
{
|
|
|
|
struct sched_domain_shared *sds;
|
|
|
|
|
|
|
|
sds = rcu_dereference(per_cpu(sd_llc_shared, cpu));
|
|
|
|
if (sds)
|
|
|
|
WRITE_ONCE(sds->has_idle_cores, val);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool test_idle_cores(int cpu, bool def)
|
|
|
|
{
|
|
|
|
struct sched_domain_shared *sds;
|
|
|
|
|
|
|
|
sds = rcu_dereference(per_cpu(sd_llc_shared, cpu));
|
|
|
|
if (sds)
|
|
|
|
return READ_ONCE(sds->has_idle_cores);
|
|
|
|
|
|
|
|
return def;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scans the local SMT mask to see if the entire core is idle, and records this
|
|
|
|
* information in sd_llc_shared->has_idle_cores.
|
|
|
|
*
|
|
|
|
* Since SMT siblings share all cache levels, inspecting this limited remote
|
|
|
|
* state should be fairly cheap.
|
|
|
|
*/
|
2016-05-09 08:38:41 +00:00
|
|
|
void __update_idle_core(struct rq *rq)
|
2016-05-09 08:38:05 +00:00
|
|
|
{
|
|
|
|
int core = cpu_of(rq);
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
if (test_idle_cores(core, true))
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
for_each_cpu(cpu, cpu_smt_mask(core)) {
|
|
|
|
if (cpu == core)
|
|
|
|
continue;
|
|
|
|
|
2018-05-09 16:39:48 +00:00
|
|
|
if (!available_idle_cpu(cpu))
|
2016-05-09 08:38:05 +00:00
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
set_idle_cores(core, 1);
|
|
|
|
unlock:
|
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan the entire LLC domain for idle cores; this dynamically switches off if
|
|
|
|
* there are no idle cores left in the system; tracked through
|
|
|
|
* sd_llc->shared->has_idle_cores and enabled through update_idle_core() above.
|
|
|
|
*/
|
|
|
|
static int select_idle_core(struct task_struct *p, struct sched_domain *sd, int target)
|
|
|
|
{
|
|
|
|
struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
|
2017-04-14 12:20:05 +00:00
|
|
|
int core, cpu;
|
2016-05-09 08:38:05 +00:00
|
|
|
|
2016-05-09 08:38:41 +00:00
|
|
|
if (!static_branch_likely(&sched_smt_present))
|
|
|
|
return -1;
|
|
|
|
|
2016-05-09 08:38:05 +00:00
|
|
|
if (!test_idle_cores(target, false))
|
|
|
|
return -1;
|
|
|
|
|
2019-04-23 14:26:36 +00:00
|
|
|
cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
|
2016-05-09 08:38:05 +00:00
|
|
|
|
2017-04-14 12:20:05 +00:00
|
|
|
for_each_cpu_wrap(core, cpus, target) {
|
2016-05-09 08:38:05 +00:00
|
|
|
bool idle = true;
|
|
|
|
|
|
|
|
for_each_cpu(cpu, cpu_smt_mask(core)) {
|
2019-02-12 09:27:01 +00:00
|
|
|
__cpumask_clear_cpu(cpu, cpus);
|
2018-05-09 16:39:48 +00:00
|
|
|
if (!available_idle_cpu(cpu))
|
2016-05-09 08:38:05 +00:00
|
|
|
idle = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (idle)
|
|
|
|
return core;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Failed to find an idle core; stop looking for one.
|
|
|
|
*/
|
|
|
|
set_idle_cores(target, 0);
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan the local SMT mask for idle CPUs.
|
|
|
|
*/
|
2019-02-07 10:46:05 +00:00
|
|
|
static int select_idle_smt(struct task_struct *p, int target)
|
2016-05-09 08:38:05 +00:00
|
|
|
{
|
2019-11-14 10:49:27 +00:00
|
|
|
int cpu;
|
2016-05-09 08:38:05 +00:00
|
|
|
|
2016-05-09 08:38:41 +00:00
|
|
|
if (!static_branch_likely(&sched_smt_present))
|
|
|
|
return -1;
|
|
|
|
|
2016-05-09 08:38:05 +00:00
|
|
|
for_each_cpu(cpu, cpu_smt_mask(target)) {
|
2019-04-23 14:26:36 +00:00
|
|
|
if (!cpumask_test_cpu(cpu, p->cpus_ptr))
|
2016-05-09 08:38:05 +00:00
|
|
|
continue;
|
2019-11-14 10:49:27 +00:00
|
|
|
if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
|
2016-05-09 08:38:05 +00:00
|
|
|
return cpu;
|
|
|
|
}
|
|
|
|
|
2019-11-14 10:49:27 +00:00
|
|
|
return -1;
|
2016-05-09 08:38:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#else /* CONFIG_SCHED_SMT */
|
|
|
|
|
|
|
|
static inline int select_idle_core(struct task_struct *p, struct sched_domain *sd, int target)
|
|
|
|
{
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2019-02-07 10:46:05 +00:00
|
|
|
static inline int select_idle_smt(struct task_struct *p, int target)
|
2016-05-09 08:38:05 +00:00
|
|
|
{
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_SCHED_SMT */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scan the LLC domain for idle CPUs; this is dynamically regulated by
|
|
|
|
* comparing the average scan cost (tracked in sd->avg_scan_cost) against the
|
|
|
|
* average idle time for this rq (as found in rq->avg_idle).
|
2009-11-12 14:55:28 +00:00
|
|
|
*/
|
2016-05-09 08:38:05 +00:00
|
|
|
static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int target)
|
|
|
|
{
|
2019-12-13 02:45:30 +00:00
|
|
|
struct cpumask *cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
|
2016-10-09 00:04:03 +00:00
|
|
|
struct sched_domain *this_sd;
|
2017-05-17 10:53:50 +00:00
|
|
|
u64 avg_cost, avg_idle;
|
2016-05-09 08:38:05 +00:00
|
|
|
u64 time, cost;
|
|
|
|
s64 delta;
|
2019-02-27 09:27:58 +00:00
|
|
|
int this = smp_processor_id();
|
2019-11-14 10:49:27 +00:00
|
|
|
int cpu, nr = INT_MAX;
|
2016-05-09 08:38:05 +00:00
|
|
|
|
2016-10-09 00:04:03 +00:00
|
|
|
this_sd = rcu_dereference(*this_cpu_ptr(&sd_llc));
|
|
|
|
if (!this_sd)
|
|
|
|
return -1;
|
|
|
|
|
2016-05-09 08:38:05 +00:00
|
|
|
/*
|
|
|
|
* Due to large variance we need a large fuzz factor; hackbench in
|
|
|
|
* particularly is sensitive here.
|
|
|
|
*/
|
2017-05-17 10:53:50 +00:00
|
|
|
avg_idle = this_rq()->avg_idle / 512;
|
|
|
|
avg_cost = this_sd->avg_scan_cost + 1;
|
|
|
|
|
|
|
|
if (sched_feat(SIS_AVG_CPU) && avg_idle < avg_cost)
|
2016-05-09 08:38:05 +00:00
|
|
|
return -1;
|
|
|
|
|
2017-05-17 10:53:50 +00:00
|
|
|
if (sched_feat(SIS_PROP)) {
|
|
|
|
u64 span_avg = sd->span_weight * avg_idle;
|
|
|
|
if (span_avg > 4*avg_cost)
|
|
|
|
nr = div_u64(span_avg, avg_cost);
|
|
|
|
else
|
|
|
|
nr = 4;
|
|
|
|
}
|
|
|
|
|
2019-02-27 09:27:58 +00:00
|
|
|
time = cpu_clock(this);
|
2016-05-09 08:38:05 +00:00
|
|
|
|
2019-12-13 02:45:30 +00:00
|
|
|
cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
|
|
|
|
|
|
|
|
for_each_cpu_wrap(cpu, cpus, target) {
|
2017-05-17 10:53:50 +00:00
|
|
|
if (!--nr)
|
2019-11-14 10:49:27 +00:00
|
|
|
return -1;
|
|
|
|
if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
|
2016-05-09 08:38:05 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-02-27 09:27:58 +00:00
|
|
|
time = cpu_clock(this) - time;
|
2016-05-09 08:38:05 +00:00
|
|
|
cost = this_sd->avg_scan_cost;
|
|
|
|
delta = (s64)(time - cost) / 8;
|
|
|
|
this_sd->avg_scan_cost += delta;
|
|
|
|
|
|
|
|
return cpu;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Try and locate an idle core/thread in the LLC cache domain.
|
2009-11-12 14:55:28 +00:00
|
|
|
*/
|
2016-06-22 17:03:13 +00:00
|
|
|
static int select_idle_sibling(struct task_struct *p, int prev, int target)
|
2009-11-12 14:55:28 +00:00
|
|
|
{
|
2010-03-31 23:47:45 +00:00
|
|
|
struct sched_domain *sd;
|
2018-01-30 10:45:55 +00:00
|
|
|
int i, recent_used_cpu;
|
2009-11-12 14:55:28 +00:00
|
|
|
|
2019-06-26 05:06:30 +00:00
|
|
|
if (available_idle_cpu(target) || sched_idle_cpu(target))
|
2013-01-28 11:19:25 +00:00
|
|
|
return target;
|
2010-03-31 23:47:45 +00:00
|
|
|
|
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* If the previous CPU is cache affine and idle, don't be stupid:
|
2010-03-31 23:47:45 +00:00
|
|
|
*/
|
2019-06-26 05:06:30 +00:00
|
|
|
if (prev != target && cpus_share_cache(prev, target) &&
|
|
|
|
(available_idle_cpu(prev) || sched_idle_cpu(prev)))
|
2016-06-22 17:03:13 +00:00
|
|
|
return prev;
|
2009-11-12 14:55:28 +00:00
|
|
|
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/* Check a recently used CPU as a potential idle candidate: */
|
2018-01-30 10:45:55 +00:00
|
|
|
recent_used_cpu = p->recent_used_cpu;
|
|
|
|
if (recent_used_cpu != prev &&
|
|
|
|
recent_used_cpu != target &&
|
|
|
|
cpus_share_cache(recent_used_cpu, target) &&
|
2019-06-26 05:06:30 +00:00
|
|
|
(available_idle_cpu(recent_used_cpu) || sched_idle_cpu(recent_used_cpu)) &&
|
2019-04-23 14:26:36 +00:00
|
|
|
cpumask_test_cpu(p->recent_used_cpu, p->cpus_ptr)) {
|
2018-01-30 10:45:55 +00:00
|
|
|
/*
|
|
|
|
* Replace recent_used_cpu with prev as it is a potential
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* candidate for the next wake:
|
2018-01-30 10:45:55 +00:00
|
|
|
*/
|
|
|
|
p->recent_used_cpu = prev;
|
|
|
|
return recent_used_cpu;
|
|
|
|
}
|
|
|
|
|
2011-12-07 14:07:31 +00:00
|
|
|
sd = rcu_dereference(per_cpu(sd_llc, target));
|
2016-05-09 08:38:05 +00:00
|
|
|
if (!sd)
|
|
|
|
return target;
|
2016-06-22 17:03:13 +00:00
|
|
|
|
2016-05-09 08:38:05 +00:00
|
|
|
i = select_idle_core(p, sd, target);
|
|
|
|
if ((unsigned)i < nr_cpumask_bits)
|
|
|
|
return i;
|
2012-09-16 19:29:43 +00:00
|
|
|
|
2016-05-09 08:38:05 +00:00
|
|
|
i = select_idle_cpu(p, sd, target);
|
|
|
|
if ((unsigned)i < nr_cpumask_bits)
|
|
|
|
return i;
|
|
|
|
|
2019-02-07 10:46:05 +00:00
|
|
|
i = select_idle_smt(p, target);
|
2016-05-09 08:38:05 +00:00
|
|
|
if ((unsigned)i < nr_cpumask_bits)
|
|
|
|
return i;
|
2012-06-12 03:18:32 +00:00
|
|
|
|
2009-11-12 14:55:28 +00:00
|
|
|
return target;
|
|
|
|
}
|
2015-08-14 16:23:13 +00:00
|
|
|
|
2018-03-09 09:52:43 +00:00
|
|
|
/**
|
|
|
|
* Amount of capacity of a CPU that is (estimated to be) used by CFS tasks
|
|
|
|
* @cpu: the CPU to get the utilization of
|
|
|
|
*
|
|
|
|
* The unit of the return value must be the one of capacity so we can compare
|
|
|
|
* the utilization with the capacity of the CPU that is available for CFS task
|
|
|
|
* (ie cpu_capacity).
|
2015-08-14 16:23:13 +00:00
|
|
|
*
|
|
|
|
* cfs_rq.avg.util_avg is the sum of running time of runnable tasks plus the
|
|
|
|
* recent utilization of currently non-runnable tasks on a CPU. It represents
|
|
|
|
* the amount of utilization of a CPU in the range [0..capacity_orig] where
|
|
|
|
* capacity_orig is the cpu_capacity available at the highest frequency
|
|
|
|
* (arch_scale_freq_capacity()).
|
|
|
|
* The utilization of a CPU converges towards a sum equal to or less than the
|
|
|
|
* current capacity (capacity_curr <= capacity_orig) of the CPU because it is
|
|
|
|
* the running time on this CPU scaled by capacity_curr.
|
|
|
|
*
|
2018-03-09 09:52:43 +00:00
|
|
|
* The estimated utilization of a CPU is defined to be the maximum between its
|
|
|
|
* cfs_rq.avg.util_avg and the sum of the estimated utilization of the tasks
|
|
|
|
* currently RUNNABLE on that CPU.
|
|
|
|
* This allows to properly represent the expected utilization of a CPU which
|
|
|
|
* has just got a big task running since a long sleep period. At the same time
|
|
|
|
* however it preserves the benefits of the "blocked utilization" in
|
|
|
|
* describing the potential for other tasks waking up on the same CPU.
|
|
|
|
*
|
2015-08-14 16:23:13 +00:00
|
|
|
* Nevertheless, cfs_rq.avg.util_avg can be higher than capacity_curr or even
|
|
|
|
* higher than capacity_orig because of unfortunate rounding in
|
|
|
|
* cfs.avg.util_avg or just after migrating tasks and new task wakeups until
|
|
|
|
* the average stabilizes with the new running time. We need to check that the
|
|
|
|
* utilization stays within the range of [0..capacity_orig] and cap it if
|
|
|
|
* necessary. Without utilization capping, a group could be seen as overloaded
|
|
|
|
* (CPU0 utilization at 121% + CPU1 utilization at 80%) whereas CPU1 has 20% of
|
|
|
|
* available capacity. We allow utilization to overshoot capacity_curr (but not
|
|
|
|
* capacity_orig) as it useful for predicting the capacity required after task
|
|
|
|
* migrations (scheduler-driven DVFS).
|
2018-03-09 09:52:43 +00:00
|
|
|
*
|
|
|
|
* Return: the (estimated) utilization for the specified CPU
|
2015-03-04 07:48:47 +00:00
|
|
|
*/
|
2018-03-09 09:52:43 +00:00
|
|
|
static inline unsigned long cpu_util(int cpu)
|
2015-03-04 07:48:47 +00:00
|
|
|
{
|
2018-03-09 09:52:43 +00:00
|
|
|
struct cfs_rq *cfs_rq;
|
|
|
|
unsigned int util;
|
|
|
|
|
|
|
|
cfs_rq = &cpu_rq(cpu)->cfs;
|
|
|
|
util = READ_ONCE(cfs_rq->avg.util_avg);
|
|
|
|
|
|
|
|
if (sched_feat(UTIL_EST))
|
|
|
|
util = max(util, READ_ONCE(cfs_rq->avg.util_est.enqueued));
|
2015-03-04 07:48:47 +00:00
|
|
|
|
2018-03-09 09:52:43 +00:00
|
|
|
return min_t(unsigned long, util, capacity_orig_of(cpu));
|
2015-03-04 07:48:47 +00:00
|
|
|
}
|
2009-11-12 14:55:28 +00:00
|
|
|
|
2016-10-14 13:41:07 +00:00
|
|
|
/*
|
sched/fair: Fix cpu_util_wake() for 'execl' type workloads
A ~10% regression has been reported for UnixBench's execl throughput
test by Aaron Lu and Ye Xiaolong:
https://lkml.org/lkml/2018/10/30/765
That test is pretty simple, it does a "recursive" execve() syscall on the
same binary. Starting from the syscall, this sequence is possible:
do_execve()
do_execveat_common()
__do_execve_file()
sched_exec()
select_task_rq_fair() <==| Task already enqueued
find_idlest_cpu()
find_idlest_group()
capacity_spare_wake() <==| Functions not called from
cpu_util_wake() | the wakeup path
which means we can end up calling cpu_util_wake() not only from the
"wakeup path", as its name would suggest. Indeed, the task doing an
execve() syscall is already enqueued on the CPU we want to get the
cpu_util_wake() for.
The estimated utilization for a CPU computed in cpu_util_wake() was
written under the assumption that function can be called only from the
wakeup path. If instead the task is already enqueued, we end up with a
utilization which does not remove the current task's contribution from
the estimated utilization of the CPU.
This will wrongly assume a reduced spare capacity on the current CPU and
increase the chances to migrate the task on execve.
The regression is tracked down to:
commit d519329f72a6 ("sched/fair: Update util_est only on util_avg updates")
because in that patch we turn on by default the UTIL_EST sched feature.
However, the real issue is introduced by:
commit f9be3e5961c5 ("sched/fair: Use util_est in LB and WU paths")
Let's fix this by ensuring to always discount the task estimated
utilization from the CPU's estimated utilization when the task is also
the current one. The same benchmark of the bug report, executed on a
dual socket 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz machine,
reports these "Execl Throughput" figures (higher the better):
mainline : 48136.5 lps
mainline+fix : 55376.5 lps
which correspond to a 15% speedup.
Moreover, since {cpu_util,capacity_spare}_wake() are not really only
used from the wakeup path, let's remove this ambiguity by using a better
matching name: {cpu_util,capacity_spare}_without().
Since we are at that, let's also improve the existing documentation.
Reported-by: Aaron Lu <aaron.lu@intel.com>
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Perret <quentin.perret@arm.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Fixes: f9be3e5961c5 (sched/fair: Use util_est in LB and WU paths)
Link: https://lore.kernel.org/lkml/20181025093100.GB13236@e110439-lin/
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-11-05 14:53:58 +00:00
|
|
|
* cpu_util_without: compute cpu utilization without any contributions from *p
|
|
|
|
* @cpu: the CPU which utilization is requested
|
|
|
|
* @p: the task which utilization should be discounted
|
|
|
|
*
|
|
|
|
* The utilization of a CPU is defined by the utilization of tasks currently
|
|
|
|
* enqueued on that CPU as well as tasks which are currently sleeping after an
|
|
|
|
* execution on that CPU.
|
|
|
|
*
|
|
|
|
* This method returns the utilization of the specified CPU by discounting the
|
|
|
|
* utilization of the specified task, whenever the task is currently
|
|
|
|
* contributing to the CPU utilization.
|
2016-10-14 13:41:07 +00:00
|
|
|
*/
|
sched/fair: Fix cpu_util_wake() for 'execl' type workloads
A ~10% regression has been reported for UnixBench's execl throughput
test by Aaron Lu and Ye Xiaolong:
https://lkml.org/lkml/2018/10/30/765
That test is pretty simple, it does a "recursive" execve() syscall on the
same binary. Starting from the syscall, this sequence is possible:
do_execve()
do_execveat_common()
__do_execve_file()
sched_exec()
select_task_rq_fair() <==| Task already enqueued
find_idlest_cpu()
find_idlest_group()
capacity_spare_wake() <==| Functions not called from
cpu_util_wake() | the wakeup path
which means we can end up calling cpu_util_wake() not only from the
"wakeup path", as its name would suggest. Indeed, the task doing an
execve() syscall is already enqueued on the CPU we want to get the
cpu_util_wake() for.
The estimated utilization for a CPU computed in cpu_util_wake() was
written under the assumption that function can be called only from the
wakeup path. If instead the task is already enqueued, we end up with a
utilization which does not remove the current task's contribution from
the estimated utilization of the CPU.
This will wrongly assume a reduced spare capacity on the current CPU and
increase the chances to migrate the task on execve.
The regression is tracked down to:
commit d519329f72a6 ("sched/fair: Update util_est only on util_avg updates")
because in that patch we turn on by default the UTIL_EST sched feature.
However, the real issue is introduced by:
commit f9be3e5961c5 ("sched/fair: Use util_est in LB and WU paths")
Let's fix this by ensuring to always discount the task estimated
utilization from the CPU's estimated utilization when the task is also
the current one. The same benchmark of the bug report, executed on a
dual socket 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz machine,
reports these "Execl Throughput" figures (higher the better):
mainline : 48136.5 lps
mainline+fix : 55376.5 lps
which correspond to a 15% speedup.
Moreover, since {cpu_util,capacity_spare}_wake() are not really only
used from the wakeup path, let's remove this ambiguity by using a better
matching name: {cpu_util,capacity_spare}_without().
Since we are at that, let's also improve the existing documentation.
Reported-by: Aaron Lu <aaron.lu@intel.com>
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Perret <quentin.perret@arm.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Fixes: f9be3e5961c5 (sched/fair: Use util_est in LB and WU paths)
Link: https://lore.kernel.org/lkml/20181025093100.GB13236@e110439-lin/
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-11-05 14:53:58 +00:00
|
|
|
static unsigned long cpu_util_without(int cpu, struct task_struct *p)
|
2016-10-14 13:41:07 +00:00
|
|
|
{
|
2018-03-09 09:52:43 +00:00
|
|
|
struct cfs_rq *cfs_rq;
|
|
|
|
unsigned int util;
|
2016-10-14 13:41:07 +00:00
|
|
|
|
|
|
|
/* Task has no contribution or is new */
|
2018-03-09 09:52:43 +00:00
|
|
|
if (cpu != task_cpu(p) || !READ_ONCE(p->se.avg.last_update_time))
|
2016-10-14 13:41:07 +00:00
|
|
|
return cpu_util(cpu);
|
|
|
|
|
2018-03-09 09:52:43 +00:00
|
|
|
cfs_rq = &cpu_rq(cpu)->cfs;
|
|
|
|
util = READ_ONCE(cfs_rq->avg.util_avg);
|
|
|
|
|
sched/fair: Fix cpu_util_wake() for 'execl' type workloads
A ~10% regression has been reported for UnixBench's execl throughput
test by Aaron Lu and Ye Xiaolong:
https://lkml.org/lkml/2018/10/30/765
That test is pretty simple, it does a "recursive" execve() syscall on the
same binary. Starting from the syscall, this sequence is possible:
do_execve()
do_execveat_common()
__do_execve_file()
sched_exec()
select_task_rq_fair() <==| Task already enqueued
find_idlest_cpu()
find_idlest_group()
capacity_spare_wake() <==| Functions not called from
cpu_util_wake() | the wakeup path
which means we can end up calling cpu_util_wake() not only from the
"wakeup path", as its name would suggest. Indeed, the task doing an
execve() syscall is already enqueued on the CPU we want to get the
cpu_util_wake() for.
The estimated utilization for a CPU computed in cpu_util_wake() was
written under the assumption that function can be called only from the
wakeup path. If instead the task is already enqueued, we end up with a
utilization which does not remove the current task's contribution from
the estimated utilization of the CPU.
This will wrongly assume a reduced spare capacity on the current CPU and
increase the chances to migrate the task on execve.
The regression is tracked down to:
commit d519329f72a6 ("sched/fair: Update util_est only on util_avg updates")
because in that patch we turn on by default the UTIL_EST sched feature.
However, the real issue is introduced by:
commit f9be3e5961c5 ("sched/fair: Use util_est in LB and WU paths")
Let's fix this by ensuring to always discount the task estimated
utilization from the CPU's estimated utilization when the task is also
the current one. The same benchmark of the bug report, executed on a
dual socket 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz machine,
reports these "Execl Throughput" figures (higher the better):
mainline : 48136.5 lps
mainline+fix : 55376.5 lps
which correspond to a 15% speedup.
Moreover, since {cpu_util,capacity_spare}_wake() are not really only
used from the wakeup path, let's remove this ambiguity by using a better
matching name: {cpu_util,capacity_spare}_without().
Since we are at that, let's also improve the existing documentation.
Reported-by: Aaron Lu <aaron.lu@intel.com>
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Perret <quentin.perret@arm.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Fixes: f9be3e5961c5 (sched/fair: Use util_est in LB and WU paths)
Link: https://lore.kernel.org/lkml/20181025093100.GB13236@e110439-lin/
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-11-05 14:53:58 +00:00
|
|
|
/* Discount task's util from CPU's util */
|
2018-11-05 14:54:00 +00:00
|
|
|
lsub_positive(&util, task_util(p));
|
2016-10-14 13:41:07 +00:00
|
|
|
|
2018-03-09 09:52:43 +00:00
|
|
|
/*
|
|
|
|
* Covered cases:
|
|
|
|
*
|
|
|
|
* a) if *p is the only task sleeping on this CPU, then:
|
|
|
|
* cpu_util (== task_util) > util_est (== 0)
|
|
|
|
* and thus we return:
|
sched/fair: Fix cpu_util_wake() for 'execl' type workloads
A ~10% regression has been reported for UnixBench's execl throughput
test by Aaron Lu and Ye Xiaolong:
https://lkml.org/lkml/2018/10/30/765
That test is pretty simple, it does a "recursive" execve() syscall on the
same binary. Starting from the syscall, this sequence is possible:
do_execve()
do_execveat_common()
__do_execve_file()
sched_exec()
select_task_rq_fair() <==| Task already enqueued
find_idlest_cpu()
find_idlest_group()
capacity_spare_wake() <==| Functions not called from
cpu_util_wake() | the wakeup path
which means we can end up calling cpu_util_wake() not only from the
"wakeup path", as its name would suggest. Indeed, the task doing an
execve() syscall is already enqueued on the CPU we want to get the
cpu_util_wake() for.
The estimated utilization for a CPU computed in cpu_util_wake() was
written under the assumption that function can be called only from the
wakeup path. If instead the task is already enqueued, we end up with a
utilization which does not remove the current task's contribution from
the estimated utilization of the CPU.
This will wrongly assume a reduced spare capacity on the current CPU and
increase the chances to migrate the task on execve.
The regression is tracked down to:
commit d519329f72a6 ("sched/fair: Update util_est only on util_avg updates")
because in that patch we turn on by default the UTIL_EST sched feature.
However, the real issue is introduced by:
commit f9be3e5961c5 ("sched/fair: Use util_est in LB and WU paths")
Let's fix this by ensuring to always discount the task estimated
utilization from the CPU's estimated utilization when the task is also
the current one. The same benchmark of the bug report, executed on a
dual socket 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz machine,
reports these "Execl Throughput" figures (higher the better):
mainline : 48136.5 lps
mainline+fix : 55376.5 lps
which correspond to a 15% speedup.
Moreover, since {cpu_util,capacity_spare}_wake() are not really only
used from the wakeup path, let's remove this ambiguity by using a better
matching name: {cpu_util,capacity_spare}_without().
Since we are at that, let's also improve the existing documentation.
Reported-by: Aaron Lu <aaron.lu@intel.com>
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Perret <quentin.perret@arm.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Fixes: f9be3e5961c5 (sched/fair: Use util_est in LB and WU paths)
Link: https://lore.kernel.org/lkml/20181025093100.GB13236@e110439-lin/
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-11-05 14:53:58 +00:00
|
|
|
* cpu_util_without = (cpu_util - task_util) = 0
|
2018-03-09 09:52:43 +00:00
|
|
|
*
|
|
|
|
* b) if other tasks are SLEEPING on this CPU, which is now exiting
|
|
|
|
* IDLE, then:
|
|
|
|
* cpu_util >= task_util
|
|
|
|
* cpu_util > util_est (== 0)
|
|
|
|
* and thus we discount *p's blocked utilization to return:
|
sched/fair: Fix cpu_util_wake() for 'execl' type workloads
A ~10% regression has been reported for UnixBench's execl throughput
test by Aaron Lu and Ye Xiaolong:
https://lkml.org/lkml/2018/10/30/765
That test is pretty simple, it does a "recursive" execve() syscall on the
same binary. Starting from the syscall, this sequence is possible:
do_execve()
do_execveat_common()
__do_execve_file()
sched_exec()
select_task_rq_fair() <==| Task already enqueued
find_idlest_cpu()
find_idlest_group()
capacity_spare_wake() <==| Functions not called from
cpu_util_wake() | the wakeup path
which means we can end up calling cpu_util_wake() not only from the
"wakeup path", as its name would suggest. Indeed, the task doing an
execve() syscall is already enqueued on the CPU we want to get the
cpu_util_wake() for.
The estimated utilization for a CPU computed in cpu_util_wake() was
written under the assumption that function can be called only from the
wakeup path. If instead the task is already enqueued, we end up with a
utilization which does not remove the current task's contribution from
the estimated utilization of the CPU.
This will wrongly assume a reduced spare capacity on the current CPU and
increase the chances to migrate the task on execve.
The regression is tracked down to:
commit d519329f72a6 ("sched/fair: Update util_est only on util_avg updates")
because in that patch we turn on by default the UTIL_EST sched feature.
However, the real issue is introduced by:
commit f9be3e5961c5 ("sched/fair: Use util_est in LB and WU paths")
Let's fix this by ensuring to always discount the task estimated
utilization from the CPU's estimated utilization when the task is also
the current one. The same benchmark of the bug report, executed on a
dual socket 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz machine,
reports these "Execl Throughput" figures (higher the better):
mainline : 48136.5 lps
mainline+fix : 55376.5 lps
which correspond to a 15% speedup.
Moreover, since {cpu_util,capacity_spare}_wake() are not really only
used from the wakeup path, let's remove this ambiguity by using a better
matching name: {cpu_util,capacity_spare}_without().
Since we are at that, let's also improve the existing documentation.
Reported-by: Aaron Lu <aaron.lu@intel.com>
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Perret <quentin.perret@arm.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Fixes: f9be3e5961c5 (sched/fair: Use util_est in LB and WU paths)
Link: https://lore.kernel.org/lkml/20181025093100.GB13236@e110439-lin/
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-11-05 14:53:58 +00:00
|
|
|
* cpu_util_without = (cpu_util - task_util) >= 0
|
2018-03-09 09:52:43 +00:00
|
|
|
*
|
|
|
|
* c) if other tasks are RUNNABLE on that CPU and
|
|
|
|
* util_est > cpu_util
|
|
|
|
* then we use util_est since it returns a more restrictive
|
|
|
|
* estimation of the spare capacity on that CPU, by just
|
|
|
|
* considering the expected utilization of tasks already
|
|
|
|
* runnable on that CPU.
|
|
|
|
*
|
|
|
|
* Cases a) and b) are covered by the above code, while case c) is
|
|
|
|
* covered by the following code when estimated utilization is
|
|
|
|
* enabled.
|
|
|
|
*/
|
sched/fair: Fix cpu_util_wake() for 'execl' type workloads
A ~10% regression has been reported for UnixBench's execl throughput
test by Aaron Lu and Ye Xiaolong:
https://lkml.org/lkml/2018/10/30/765
That test is pretty simple, it does a "recursive" execve() syscall on the
same binary. Starting from the syscall, this sequence is possible:
do_execve()
do_execveat_common()
__do_execve_file()
sched_exec()
select_task_rq_fair() <==| Task already enqueued
find_idlest_cpu()
find_idlest_group()
capacity_spare_wake() <==| Functions not called from
cpu_util_wake() | the wakeup path
which means we can end up calling cpu_util_wake() not only from the
"wakeup path", as its name would suggest. Indeed, the task doing an
execve() syscall is already enqueued on the CPU we want to get the
cpu_util_wake() for.
The estimated utilization for a CPU computed in cpu_util_wake() was
written under the assumption that function can be called only from the
wakeup path. If instead the task is already enqueued, we end up with a
utilization which does not remove the current task's contribution from
the estimated utilization of the CPU.
This will wrongly assume a reduced spare capacity on the current CPU and
increase the chances to migrate the task on execve.
The regression is tracked down to:
commit d519329f72a6 ("sched/fair: Update util_est only on util_avg updates")
because in that patch we turn on by default the UTIL_EST sched feature.
However, the real issue is introduced by:
commit f9be3e5961c5 ("sched/fair: Use util_est in LB and WU paths")
Let's fix this by ensuring to always discount the task estimated
utilization from the CPU's estimated utilization when the task is also
the current one. The same benchmark of the bug report, executed on a
dual socket 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz machine,
reports these "Execl Throughput" figures (higher the better):
mainline : 48136.5 lps
mainline+fix : 55376.5 lps
which correspond to a 15% speedup.
Moreover, since {cpu_util,capacity_spare}_wake() are not really only
used from the wakeup path, let's remove this ambiguity by using a better
matching name: {cpu_util,capacity_spare}_without().
Since we are at that, let's also improve the existing documentation.
Reported-by: Aaron Lu <aaron.lu@intel.com>
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Perret <quentin.perret@arm.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Fixes: f9be3e5961c5 (sched/fair: Use util_est in LB and WU paths)
Link: https://lore.kernel.org/lkml/20181025093100.GB13236@e110439-lin/
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-11-05 14:53:58 +00:00
|
|
|
if (sched_feat(UTIL_EST)) {
|
|
|
|
unsigned int estimated =
|
|
|
|
READ_ONCE(cfs_rq->avg.util_est.enqueued);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Despite the following checks we still have a small window
|
|
|
|
* for a possible race, when an execl's select_task_rq_fair()
|
|
|
|
* races with LB's detach_task():
|
|
|
|
*
|
|
|
|
* detach_task()
|
|
|
|
* p->on_rq = TASK_ON_RQ_MIGRATING;
|
|
|
|
* ---------------------------------- A
|
|
|
|
* deactivate_task() \
|
|
|
|
* dequeue_task() + RaceTime
|
|
|
|
* util_est_dequeue() /
|
|
|
|
* ---------------------------------- B
|
|
|
|
*
|
|
|
|
* The additional check on "current == p" it's required to
|
|
|
|
* properly fix the execl regression and it helps in further
|
|
|
|
* reducing the chances for the above race.
|
|
|
|
*/
|
2018-11-05 14:54:00 +00:00
|
|
|
if (unlikely(task_on_rq_queued(p) || current == p))
|
|
|
|
lsub_positive(&estimated, _task_util_est(p));
|
|
|
|
|
sched/fair: Fix cpu_util_wake() for 'execl' type workloads
A ~10% regression has been reported for UnixBench's execl throughput
test by Aaron Lu and Ye Xiaolong:
https://lkml.org/lkml/2018/10/30/765
That test is pretty simple, it does a "recursive" execve() syscall on the
same binary. Starting from the syscall, this sequence is possible:
do_execve()
do_execveat_common()
__do_execve_file()
sched_exec()
select_task_rq_fair() <==| Task already enqueued
find_idlest_cpu()
find_idlest_group()
capacity_spare_wake() <==| Functions not called from
cpu_util_wake() | the wakeup path
which means we can end up calling cpu_util_wake() not only from the
"wakeup path", as its name would suggest. Indeed, the task doing an
execve() syscall is already enqueued on the CPU we want to get the
cpu_util_wake() for.
The estimated utilization for a CPU computed in cpu_util_wake() was
written under the assumption that function can be called only from the
wakeup path. If instead the task is already enqueued, we end up with a
utilization which does not remove the current task's contribution from
the estimated utilization of the CPU.
This will wrongly assume a reduced spare capacity on the current CPU and
increase the chances to migrate the task on execve.
The regression is tracked down to:
commit d519329f72a6 ("sched/fair: Update util_est only on util_avg updates")
because in that patch we turn on by default the UTIL_EST sched feature.
However, the real issue is introduced by:
commit f9be3e5961c5 ("sched/fair: Use util_est in LB and WU paths")
Let's fix this by ensuring to always discount the task estimated
utilization from the CPU's estimated utilization when the task is also
the current one. The same benchmark of the bug report, executed on a
dual socket 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz machine,
reports these "Execl Throughput" figures (higher the better):
mainline : 48136.5 lps
mainline+fix : 55376.5 lps
which correspond to a 15% speedup.
Moreover, since {cpu_util,capacity_spare}_wake() are not really only
used from the wakeup path, let's remove this ambiguity by using a better
matching name: {cpu_util,capacity_spare}_without().
Since we are at that, let's also improve the existing documentation.
Reported-by: Aaron Lu <aaron.lu@intel.com>
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Tested-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Morten Rasmussen <morten.rasmussen@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Perret <quentin.perret@arm.com>
Cc: Steve Muckle <smuckle@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Todd Kjos <tkjos@google.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Fixes: f9be3e5961c5 (sched/fair: Use util_est in LB and WU paths)
Link: https://lore.kernel.org/lkml/20181025093100.GB13236@e110439-lin/
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-11-05 14:53:58 +00:00
|
|
|
util = max(util, estimated);
|
|
|
|
}
|
2018-03-09 09:52:43 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Utilization (estimated) can exceed the CPU capacity, thus let's
|
|
|
|
* clamp to the maximum CPU capacity to ensure consistency with
|
|
|
|
* the cpu_util call.
|
|
|
|
*/
|
|
|
|
return min_t(unsigned long, util, capacity_orig_of(cpu));
|
2016-10-14 13:41:07 +00:00
|
|
|
}
|
|
|
|
|
2016-07-25 13:34:26 +00:00
|
|
|
/*
|
|
|
|
* Disable WAKE_AFFINE in the case where task @p doesn't fit in the
|
|
|
|
* capacity of either the waking CPU @cpu or the previous CPU @prev_cpu.
|
|
|
|
*
|
|
|
|
* In that case WAKE_AFFINE doesn't make sense and we'll let
|
|
|
|
* BALANCE_WAKE sort things out.
|
|
|
|
*/
|
|
|
|
static int wake_cap(struct task_struct *p, int cpu, int prev_cpu)
|
|
|
|
{
|
|
|
|
long min_cap, max_cap;
|
|
|
|
|
2018-07-04 10:17:39 +00:00
|
|
|
if (!static_branch_unlikely(&sched_asym_cpucapacity))
|
|
|
|
return 0;
|
|
|
|
|
2016-07-25 13:34:26 +00:00
|
|
|
min_cap = min(capacity_orig_of(prev_cpu), capacity_orig_of(cpu));
|
|
|
|
max_cap = cpu_rq(cpu)->rd->max_cpu_capacity;
|
|
|
|
|
|
|
|
/* Minimum capacity is close to max, no need to abort wake_affine */
|
|
|
|
if (max_cap - min_cap < max_cap >> 3)
|
|
|
|
return 0;
|
|
|
|
|
2016-10-14 13:41:07 +00:00
|
|
|
/* Bring task utilization in sync with prev_cpu */
|
|
|
|
sync_entity_load_avg(&p->se);
|
|
|
|
|
2018-07-04 10:17:40 +00:00
|
|
|
return !task_fits_capacity(p, min_cap);
|
2016-07-25 13:34:26 +00:00
|
|
|
}
|
|
|
|
|
2018-12-03 09:56:26 +00:00
|
|
|
/*
|
|
|
|
* Predicts what cpu_util(@cpu) would return if @p was migrated (and enqueued)
|
|
|
|
* to @dst_cpu.
|
|
|
|
*/
|
|
|
|
static unsigned long cpu_util_next(int cpu, struct task_struct *p, int dst_cpu)
|
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq = &cpu_rq(cpu)->cfs;
|
|
|
|
unsigned long util_est, util = READ_ONCE(cfs_rq->avg.util_avg);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If @p migrates from @cpu to another, remove its contribution. Or,
|
|
|
|
* if @p migrates from another CPU to @cpu, add its contribution. In
|
|
|
|
* the other cases, @cpu is not impacted by the migration, so the
|
|
|
|
* util_avg should already be correct.
|
|
|
|
*/
|
|
|
|
if (task_cpu(p) == cpu && dst_cpu != cpu)
|
|
|
|
sub_positive(&util, task_util(p));
|
|
|
|
else if (task_cpu(p) != cpu && dst_cpu == cpu)
|
|
|
|
util += task_util(p);
|
|
|
|
|
|
|
|
if (sched_feat(UTIL_EST)) {
|
|
|
|
util_est = READ_ONCE(cfs_rq->avg.util_est.enqueued);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* During wake-up, the task isn't enqueued yet and doesn't
|
|
|
|
* appear in the cfs_rq->avg.util_est.enqueued of any rq,
|
|
|
|
* so just add it (if needed) to "simulate" what will be
|
|
|
|
* cpu_util() after the task has been enqueued.
|
|
|
|
*/
|
|
|
|
if (dst_cpu == cpu)
|
|
|
|
util_est += _task_util_est(p);
|
|
|
|
|
|
|
|
util = max(util, util_est);
|
|
|
|
}
|
|
|
|
|
|
|
|
return min(util, capacity_orig_of(cpu));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
* compute_energy(): Estimates the energy that @pd would consume if @p was
|
2018-12-03 09:56:26 +00:00
|
|
|
* migrated to @dst_cpu. compute_energy() predicts what will be the utilization
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
* landscape of @pd's CPUs after the task migration, and uses the Energy Model
|
2018-12-03 09:56:26 +00:00
|
|
|
* to compute what would be the energy if we decided to actually migrate that
|
|
|
|
* task.
|
|
|
|
*/
|
|
|
|
static long
|
|
|
|
compute_energy(struct task_struct *p, int dst_cpu, struct perf_domain *pd)
|
|
|
|
{
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
struct cpumask *pd_mask = perf_domain_span(pd);
|
|
|
|
unsigned long cpu_cap = arch_scale_cpu_capacity(cpumask_first(pd_mask));
|
|
|
|
unsigned long max_util = 0, sum_util = 0;
|
2018-12-03 09:56:26 +00:00
|
|
|
int cpu;
|
|
|
|
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
/*
|
|
|
|
* The capacity state of CPUs of the current rd can be driven by CPUs
|
|
|
|
* of another rd if they belong to the same pd. So, account for the
|
|
|
|
* utilization of these CPUs too by masking pd with cpu_online_mask
|
|
|
|
* instead of the rd span.
|
|
|
|
*
|
|
|
|
* If an entire pd is outside of the current rd, it will not appear in
|
|
|
|
* its pd list and will not be accounted by compute_energy().
|
|
|
|
*/
|
|
|
|
for_each_cpu_and(cpu, pd_mask, cpu_online_mask) {
|
|
|
|
unsigned long cpu_util, util_cfs = cpu_util_next(cpu, p, dst_cpu);
|
|
|
|
struct task_struct *tsk = cpu == dst_cpu ? p : NULL;
|
2019-06-21 08:42:12 +00:00
|
|
|
|
|
|
|
/*
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
* Busy time computation: utilization clamping is not
|
|
|
|
* required since the ratio (sum_util / cpu_capacity)
|
|
|
|
* is already enough to scale the EM reported power
|
|
|
|
* consumption at the (eventually clamped) cpu_capacity.
|
2019-06-21 08:42:12 +00:00
|
|
|
*/
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
sum_util += schedutil_cpu_util(cpu, util_cfs, cpu_cap,
|
|
|
|
ENERGY_UTIL, NULL);
|
2019-06-21 08:42:12 +00:00
|
|
|
|
2018-12-03 09:56:26 +00:00
|
|
|
/*
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
* Performance domain frequency: utilization clamping
|
|
|
|
* must be considered since it affects the selection
|
|
|
|
* of the performance domain frequency.
|
|
|
|
* NOTE: in case RT tasks are running, by default the
|
|
|
|
* FREQUENCY_UTIL's utilization can be max OPP.
|
2018-12-03 09:56:26 +00:00
|
|
|
*/
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
cpu_util = schedutil_cpu_util(cpu, util_cfs, cpu_cap,
|
|
|
|
FREQUENCY_UTIL, tsk);
|
|
|
|
max_util = max(max_util, cpu_util);
|
2018-12-03 09:56:26 +00:00
|
|
|
}
|
|
|
|
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
return em_pd_energy(pd->em_pd, max_util, sum_util);
|
2018-12-03 09:56:26 +00:00
|
|
|
}
|
|
|
|
|
2018-12-03 09:56:27 +00:00
|
|
|
/*
|
|
|
|
* find_energy_efficient_cpu(): Find most energy-efficient target CPU for the
|
|
|
|
* waking task. find_energy_efficient_cpu() looks for the CPU with maximum
|
|
|
|
* spare capacity in each performance domain and uses it as a potential
|
|
|
|
* candidate to execute the task. Then, it uses the Energy Model to figure
|
|
|
|
* out which of the CPU candidates is the most energy-efficient.
|
|
|
|
*
|
|
|
|
* The rationale for this heuristic is as follows. In a performance domain,
|
|
|
|
* all the most energy efficient CPU candidates (according to the Energy
|
|
|
|
* Model) are those for which we'll request a low frequency. When there are
|
|
|
|
* several CPUs for which the frequency request will be the same, we don't
|
|
|
|
* have enough data to break the tie between them, because the Energy Model
|
|
|
|
* only includes active power costs. With this model, if we assume that
|
|
|
|
* frequency requests follow utilization (e.g. using schedutil), the CPU with
|
|
|
|
* the maximum spare capacity in a performance domain is guaranteed to be among
|
|
|
|
* the best candidates of the performance domain.
|
|
|
|
*
|
|
|
|
* In practice, it could be preferable from an energy standpoint to pack
|
|
|
|
* small tasks on a CPU in order to let other CPUs go in deeper idle states,
|
|
|
|
* but that could also hurt our chances to go cluster idle, and we have no
|
|
|
|
* ways to tell with the current Energy Model if this is actually a good
|
|
|
|
* idea or not. So, find_energy_efficient_cpu() basically favors
|
|
|
|
* cluster-packing, and spreading inside a cluster. That should at least be
|
|
|
|
* a good thing for latency, and this is consistent with the idea that most
|
|
|
|
* of the energy savings of EAS come from the asymmetry of the system, and
|
|
|
|
* not so much from breaking the tie between identical CPUs. That's also the
|
|
|
|
* reason why EAS is enabled in the topology code only for systems where
|
|
|
|
* SD_ASYM_CPUCAPACITY is set.
|
|
|
|
*
|
|
|
|
* NOTE: Forkees are not accepted in the energy-aware wake-up path because
|
|
|
|
* they don't have any useful utilization data yet and it's not possible to
|
|
|
|
* forecast their impact on energy consumption. Consequently, they will be
|
|
|
|
* placed by find_idlest_cpu() on the least loaded CPU, which might turn out
|
|
|
|
* to be energy-inefficient in some use-cases. The alternative would be to
|
|
|
|
* bias new tasks towards specific types of CPUs first, or to try to infer
|
|
|
|
* their util_avg from the parent task, but those heuristics could hurt
|
|
|
|
* other use-cases too. So, until someone finds a better way to solve this,
|
|
|
|
* let's keep things simple by re-using the existing slow path.
|
|
|
|
*/
|
|
|
|
static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
|
|
|
|
{
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
unsigned long prev_delta = ULONG_MAX, best_delta = ULONG_MAX;
|
2018-12-03 09:56:27 +00:00
|
|
|
struct root_domain *rd = cpu_rq(smp_processor_id())->rd;
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
unsigned long cpu_cap, util, base_energy = 0;
|
2018-12-03 09:56:27 +00:00
|
|
|
int cpu, best_energy_cpu = prev_cpu;
|
|
|
|
struct sched_domain *sd;
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
struct perf_domain *pd;
|
2018-12-03 09:56:27 +00:00
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
pd = rcu_dereference(rd->pd);
|
|
|
|
if (!pd || READ_ONCE(rd->overutilized))
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Energy-aware wake-up happens on the lowest sched_domain starting
|
|
|
|
* from sd_asym_cpucapacity spanning over this_cpu and prev_cpu.
|
|
|
|
*/
|
|
|
|
sd = rcu_dereference(*this_cpu_ptr(&sd_asym_cpucapacity));
|
|
|
|
while (sd && !cpumask_test_cpu(prev_cpu, sched_domain_span(sd)))
|
|
|
|
sd = sd->parent;
|
|
|
|
if (!sd)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
sync_entity_load_avg(&p->se);
|
|
|
|
if (!task_util_est(p))
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
for (; pd; pd = pd->next) {
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
unsigned long cur_delta, spare_cap, max_spare_cap = 0;
|
|
|
|
unsigned long base_energy_pd;
|
2018-12-03 09:56:27 +00:00
|
|
|
int max_spare_cap_cpu = -1;
|
|
|
|
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
/* Compute the 'base' energy of the pd, without @p */
|
|
|
|
base_energy_pd = compute_energy(p, -1, pd);
|
|
|
|
base_energy += base_energy_pd;
|
|
|
|
|
2018-12-03 09:56:27 +00:00
|
|
|
for_each_cpu_and(cpu, perf_domain_span(pd), sched_domain_span(sd)) {
|
2019-04-23 14:26:36 +00:00
|
|
|
if (!cpumask_test_cpu(cpu, p->cpus_ptr))
|
2018-12-03 09:56:27 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
util = cpu_util_next(cpu, p, cpu);
|
|
|
|
cpu_cap = capacity_of(cpu);
|
sched/fair: Make EAS wakeup placement consider uclamp restrictions
task_fits_capacity() has just been made uclamp-aware, and
find_energy_efficient_cpu() needs to go through the same treatment.
Things are somewhat different here however - using the task max clamp isn't
sufficient. Consider the following setup:
The target runqueue, rq:
rq.cpu_capacity_orig = 512
rq.cfs.avg.util_avg = 200
rq.uclamp.max = 768 // the max p.uclamp.max of all enqueued p's is 768
The waking task, p (not yet enqueued on rq):
p.util_est = 600
p.uclamp.max = 100
Now, consider the following code which doesn't use the rq clamps:
util = uclamp_task_util(p);
// Does the task fit in the spare CPU capacity?
cpu = cpu_of(rq);
fits_capacity(util, cpu_capacity(cpu) - cpu_util(cpu))
This would lead to:
util = 100;
fits_capacity(100, 512 - 200)
fits_capacity() would return true. However, enqueuing p on that CPU *will*
cause it to become overutilized since rq clamp values are max-aggregated,
so we'd remain with
rq.uclamp.max = 768
which comes from the other tasks already enqueued on rq. Thus, we could
select a high enough frequency to reach beyond 0.8 * 512 utilization
(== overutilized) after enqueuing p on rq. What find_energy_efficient_cpu()
needs here is uclamp_rq_util_with() which lets us peek at the future
utilization landscape, including rq-wide uclamp values.
Make find_energy_efficient_cpu() use uclamp_rq_util_with() for its
fits_capacity() check. This is in line with what compute_energy() ends up
using for estimating utilization.
Tested-By: Dietmar Eggemann <dietmar.eggemann@arm.com>
Suggested-by: Quentin Perret <qperret@google.com>
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20191211113851.24241-6-valentin.schneider@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-11 11:38:51 +00:00
|
|
|
spare_cap = cpu_cap - util;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip CPUs that cannot satisfy the capacity request.
|
|
|
|
* IOW, placing the task there would make the CPU
|
|
|
|
* overutilized. Take uclamp into account to see how
|
|
|
|
* much capacity we can get out of the CPU; this is
|
|
|
|
* aligned with schedutil_cpu_util().
|
|
|
|
*/
|
|
|
|
util = uclamp_rq_util_with(cpu_rq(cpu), util, p);
|
2019-06-04 07:01:52 +00:00
|
|
|
if (!fits_capacity(util, cpu_cap))
|
2018-12-03 09:56:27 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Always use prev_cpu as a candidate. */
|
|
|
|
if (cpu == prev_cpu) {
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
prev_delta = compute_energy(p, prev_cpu, pd);
|
|
|
|
prev_delta -= base_energy_pd;
|
|
|
|
best_delta = min(best_delta, prev_delta);
|
2018-12-03 09:56:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the CPU with the maximum spare capacity in
|
|
|
|
* the performance domain
|
|
|
|
*/
|
|
|
|
if (spare_cap > max_spare_cap) {
|
|
|
|
max_spare_cap = spare_cap;
|
|
|
|
max_spare_cap_cpu = cpu;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Evaluate the energy impact of using this CPU. */
|
2019-09-20 09:41:15 +00:00
|
|
|
if (max_spare_cap_cpu >= 0 && max_spare_cap_cpu != prev_cpu) {
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
cur_delta = compute_energy(p, max_spare_cap_cpu, pd);
|
|
|
|
cur_delta -= base_energy_pd;
|
|
|
|
if (cur_delta < best_delta) {
|
|
|
|
best_delta = cur_delta;
|
2018-12-03 09:56:27 +00:00
|
|
|
best_energy_cpu = max_spare_cap_cpu;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
unlock:
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Pick the best CPU if prev_cpu cannot be used, or if it saves at
|
|
|
|
* least 6% of the energy used by prev_cpu.
|
|
|
|
*/
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
if (prev_delta == ULONG_MAX)
|
2018-12-03 09:56:27 +00:00
|
|
|
return best_energy_cpu;
|
|
|
|
|
sched/fair: Speed-up energy-aware wake-ups
EAS computes the energy impact of migrating a waking task when deciding
on which CPU it should run. However, the current approach is known to
have a high algorithmic complexity, which can result in prohibitively
high wake-up latencies on systems with complex energy models, such as
systems with per-CPU DVFS. On such systems, the algorithm complexity is
in O(n^2) (ignoring the cost of searching for performance states in the
EM) with 'n' the number of CPUs.
To address this, re-factor the EAS wake-up path to compute the energy
'delta' (with and without the task) on a per-performance domain basis,
rather than system-wide, which brings the complexity down to O(n).
No functional changes intended.
Test results
~~~~~~~~~~~~
* Setup: Tested on a Google Pixel 3, with a Snapdragon 845 (4+4 CPUs,
A55/A75). Base kernel is 5.3-rc5 + Pixel3 specific patches. Android
userspace, no graphics.
* Test case: Run a periodic rt-app task, with 16ms period, ramping down
from 70% to 10%, in 5% steps of 500 ms each (json avail. at [1]).
Frequencies of all CPUs are pinned to max (using scaling_min_freq
CPUFreq sysfs entries) to reduce variability. The time to run
select_task_rq_fair() is measured using the function profiler
(/sys/kernel/debug/tracing/trace_stat/function*). See the test script
for more details [2].
Test 1:
I hacked the DT to 'fake' per-CPU DVFS. That is, we end up with one
CPUFreq policy per CPU (8 policies in total). Since all frequencies are
pinned to max for the test, this should have no impact on the actual
frequency selection, but it does in the EAS calculation.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 274 | 38.303 | 1750.239 | 401 | 14.126 (-63.1%) | 146.625 |
| 1 | 197 | 49.529 | 1695.852 | 314 | 16.135 (-67.4%) | 167.525 |
| 2 | 142 | 34.296 | 1758.665 | 302 | 14.133 (-58.8%) | 130.071 |
| 3 | 172 | 31.734 | 1490.975 | 641 | 14.637 (-53.9%) | 139.189 |
| 4 | 316 | 7.834 | 178.217 | 425 | 5.413 (-30.9%) | 20.803 |
| 5 | 447 | 8.424 | 144.638 | 556 | 5.929 (-29.6%) | 27.301 |
| 6 | 581 | 14.886 | 346.793 | 456 | 5.711 (-61.6%) | 23.124 |
| 7 | 456 | 10.005 | 211.187 | 997 | 4.708 (-52.9%) | 21.144 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
Test 2:
I also ran the same test with a normal DT, with 2 CPUFreq policies, to
see if this causes regressions in the most common case.
+---------------------------+----------------------------------+
| Without patch | With patch |
+-----+-----+----------+----------+-----+-----------------+----------+
| CPU | Hit | Avg (us) | s^2 (us) | Hit | Avg (us) | s^2 (us) |
|-----+-----+----------+----------+-----+-----------------+----------+
| 0 | 345 | 22.184 | 215.321 | 580 | 18.635 (-16.0%) | 146.892 |
| 1 | 358 | 18.597 | 200.596 | 438 | 12.934 (-30.5%) | 104.604 |
| 2 | 359 | 25.566 | 200.217 | 397 | 10.826 (-57.7%) | 74.021 |
| 3 | 362 | 16.881 | 200.291 | 718 | 11.455 (-32.1%) | 102.280 |
| 4 | 457 | 3.822 | 9.895 | 757 | 4.616 (+20.8%) | 13.369 |
| 5 | 344 | 4.301 | 7.121 | 594 | 5.320 (+23.7%) | 18.798 |
| 6 | 472 | 4.326 | 7.849 | 464 | 5.648 (+30.6%) | 22.022 |
| 7 | 331 | 4.630 | 13.937 | 408 | 5.299 (+14.4%) | 18.273 |
+-----+-----+----------+----------+-----+-----------------+----------+
* Hit, Avg and s^2 are as reported by the function profiler
In addition to these two tests, I also ran 50 iterations of the Lisa
EAS functional test suite [3] with this patch applied on Arm Juno r0,
Arm Juno r2, Arm TC2 and Hikey960, and could not see any regressions
(all EAS functional tests are passing).
[1] https://paste.debian.net/1100055/
[2] https://paste.debian.net/1100057/
[3] https://github.com/ARM-software/lisa/blob/master/lisa/tests/scheduler/eas_behaviour.py
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: juri.lelli@redhat.com
Cc: morten.rasmussen@arm.com
Cc: qais.yousef@arm.com
Cc: qperret@qperret.net
Cc: rjw@rjwysocki.net
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Link: https://lkml.kernel.org/r/20190912094404.13802-1-qperret@qperret.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-09-12 09:44:04 +00:00
|
|
|
if ((prev_delta - best_delta) > ((prev_delta + base_energy) >> 4))
|
2018-12-03 09:56:27 +00:00
|
|
|
return best_energy_cpu;
|
|
|
|
|
|
|
|
return prev_cpu;
|
|
|
|
|
|
|
|
fail:
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2009-09-10 11:36:25 +00:00
|
|
|
/*
|
2014-02-18 14:14:24 +00:00
|
|
|
* select_task_rq_fair: Select target runqueue for the waking task in domains
|
|
|
|
* that have the 'sd_flag' flag set. In practice, this is SD_BALANCE_WAKE,
|
|
|
|
* SD_BALANCE_FORK, or SD_BALANCE_EXEC.
|
2009-09-10 11:36:25 +00:00
|
|
|
*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Balances load by selecting the idlest CPU in the idlest group, or under
|
|
|
|
* certain conditions an idle sibling CPU if the domain has SD_WAKE_AFFINE set.
|
2009-09-10 11:36:25 +00:00
|
|
|
*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Returns the target CPU number.
|
2009-09-10 11:36:25 +00:00
|
|
|
*
|
|
|
|
* preempt must be disabled.
|
|
|
|
*/
|
2010-03-24 17:34:10 +00:00
|
|
|
static int
|
2013-10-07 10:29:16 +00:00
|
|
|
select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int wake_flags)
|
2009-09-10 11:36:25 +00:00
|
|
|
{
|
2018-04-26 10:30:50 +00:00
|
|
|
struct sched_domain *tmp, *sd = NULL;
|
sched: Merge select_task_rq_fair() and sched_balance_self()
The problem with wake_idle() is that is doesn't respect things like
cpu_power, which means it doesn't deal well with SMT nor the recent
RT interaction.
To cure this, it needs to do what sched_balance_self() does, which
leads to the possibility of merging select_task_rq_fair() and
sched_balance_self().
Modify sched_balance_self() to:
- update_shares() when walking up the domain tree,
(it only called it for the top domain, but it should
have done this anyway), which allows us to remove
this ugly bit from try_to_wake_up().
- do wake_affine() on the smallest domain that contains
both this (the waking) and the prev (the wakee) cpu for
WAKE invocations.
Then use the top-down balance steps it had to replace wake_idle().
This leads to the dissapearance of SD_WAKE_BALANCE and
SD_WAKE_IDLE_FAR, with SD_WAKE_IDLE replaced with SD_BALANCE_WAKE.
SD_WAKE_AFFINE needs SD_BALANCE_WAKE to be effective.
Touch all topology bits to replace the old with new SD flags --
platforms might need re-tuning, enabling SD_BALANCE_WAKE
conditionally on a NUMA distance seems like a good additional
feature, magny-core and small nehalem systems would want this
enabled, systems with slow interconnects would not.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-10 11:50:02 +00:00
|
|
|
int cpu = smp_processor_id();
|
2015-07-14 15:39:50 +00:00
|
|
|
int new_cpu = prev_cpu;
|
2010-03-31 23:47:45 +00:00
|
|
|
int want_affine = 0;
|
2018-02-13 13:37:28 +00:00
|
|
|
int sync = (wake_flags & WF_SYNC) && !(current->flags & PF_EXITING);
|
sched: Merge select_task_rq_fair() and sched_balance_self()
The problem with wake_idle() is that is doesn't respect things like
cpu_power, which means it doesn't deal well with SMT nor the recent
RT interaction.
To cure this, it needs to do what sched_balance_self() does, which
leads to the possibility of merging select_task_rq_fair() and
sched_balance_self().
Modify sched_balance_self() to:
- update_shares() when walking up the domain tree,
(it only called it for the top domain, but it should
have done this anyway), which allows us to remove
this ugly bit from try_to_wake_up().
- do wake_affine() on the smallest domain that contains
both this (the waking) and the prev (the wakee) cpu for
WAKE invocations.
Then use the top-down balance steps it had to replace wake_idle().
This leads to the dissapearance of SD_WAKE_BALANCE and
SD_WAKE_IDLE_FAR, with SD_WAKE_IDLE replaced with SD_BALANCE_WAKE.
SD_WAKE_AFFINE needs SD_BALANCE_WAKE to be effective.
Touch all topology bits to replace the old with new SD flags --
platforms might need re-tuning, enabling SD_BALANCE_WAKE
conditionally on a NUMA distance seems like a good additional
feature, magny-core and small nehalem systems would want this
enabled, systems with slow interconnects would not.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-10 11:50:02 +00:00
|
|
|
|
2016-05-12 07:19:59 +00:00
|
|
|
if (sd_flag & SD_BALANCE_WAKE) {
|
|
|
|
record_wakee(p);
|
2018-12-03 09:56:27 +00:00
|
|
|
|
2018-12-05 10:23:56 +00:00
|
|
|
if (sched_energy_enabled()) {
|
2018-12-03 09:56:27 +00:00
|
|
|
new_cpu = find_energy_efficient_cpu(p, prev_cpu);
|
|
|
|
if (new_cpu >= 0)
|
|
|
|
return new_cpu;
|
|
|
|
new_cpu = prev_cpu;
|
|
|
|
}
|
|
|
|
|
|
|
|
want_affine = !wake_wide(p) && !wake_cap(p, cpu, prev_cpu) &&
|
2019-04-23 14:26:36 +00:00
|
|
|
cpumask_test_cpu(cpu, p->cpus_ptr);
|
2016-05-12 07:19:59 +00:00
|
|
|
}
|
2009-09-10 11:36:25 +00:00
|
|
|
|
2011-04-07 12:09:50 +00:00
|
|
|
rcu_read_lock();
|
2009-09-10 11:36:25 +00:00
|
|
|
for_each_domain(cpu, tmp) {
|
2009-12-16 17:04:34 +00:00
|
|
|
if (!(tmp->flags & SD_LOAD_BALANCE))
|
2015-07-14 15:39:50 +00:00
|
|
|
break;
|
2009-12-16 17:04:34 +00:00
|
|
|
|
2009-11-12 14:55:29 +00:00
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* If both 'cpu' and 'prev_cpu' are part of this domain,
|
2010-03-31 23:47:45 +00:00
|
|
|
* cpu is a valid SD_WAKE_AFFINE target.
|
2009-11-12 14:55:29 +00:00
|
|
|
*/
|
2010-03-31 23:47:45 +00:00
|
|
|
if (want_affine && (tmp->flags & SD_WAKE_AFFINE) &&
|
|
|
|
cpumask_test_cpu(prev_cpu, sched_domain_span(tmp))) {
|
2018-04-26 10:30:50 +00:00
|
|
|
if (cpu != prev_cpu)
|
|
|
|
new_cpu = wake_affine(tmp, p, cpu, prev_cpu, sync);
|
|
|
|
|
|
|
|
sd = NULL; /* Prefer wake_affine over balance flags */
|
2009-09-17 07:01:14 +00:00
|
|
|
break;
|
2012-07-26 00:55:34 +00:00
|
|
|
}
|
2009-09-17 07:01:14 +00:00
|
|
|
|
2012-07-26 00:55:34 +00:00
|
|
|
if (tmp->flags & sd_flag)
|
2009-09-17 07:01:14 +00:00
|
|
|
sd = tmp;
|
2015-07-14 15:39:50 +00:00
|
|
|
else if (!want_affine)
|
|
|
|
break;
|
2009-09-17 07:01:14 +00:00
|
|
|
}
|
|
|
|
|
2018-04-26 10:30:50 +00:00
|
|
|
if (unlikely(sd)) {
|
|
|
|
/* Slow path */
|
2017-10-05 11:45:12 +00:00
|
|
|
new_cpu = find_idlest_cpu(sd, p, cpu, prev_cpu, sd_flag);
|
2018-04-26 10:30:50 +00:00
|
|
|
} else if (sd_flag & SD_BALANCE_WAKE) { /* XXX always ? */
|
|
|
|
/* Fast path */
|
|
|
|
|
|
|
|
new_cpu = select_idle_sibling(p, prev_cpu, new_cpu);
|
|
|
|
|
|
|
|
if (want_affine)
|
|
|
|
current->recent_used_cpu = cpu;
|
2008-01-25 20:08:09 +00:00
|
|
|
}
|
2011-04-07 12:09:50 +00:00
|
|
|
rcu_read_unlock();
|
2008-01-25 20:08:09 +00:00
|
|
|
|
sched: Merge select_task_rq_fair() and sched_balance_self()
The problem with wake_idle() is that is doesn't respect things like
cpu_power, which means it doesn't deal well with SMT nor the recent
RT interaction.
To cure this, it needs to do what sched_balance_self() does, which
leads to the possibility of merging select_task_rq_fair() and
sched_balance_self().
Modify sched_balance_self() to:
- update_shares() when walking up the domain tree,
(it only called it for the top domain, but it should
have done this anyway), which allows us to remove
this ugly bit from try_to_wake_up().
- do wake_affine() on the smallest domain that contains
both this (the waking) and the prev (the wakee) cpu for
WAKE invocations.
Then use the top-down balance steps it had to replace wake_idle().
This leads to the dissapearance of SD_WAKE_BALANCE and
SD_WAKE_IDLE_FAR, with SD_WAKE_IDLE replaced with SD_BALANCE_WAKE.
SD_WAKE_AFFINE needs SD_BALANCE_WAKE to be effective.
Touch all topology bits to replace the old with new SD flags --
platforms might need re-tuning, enabling SD_BALANCE_WAKE
conditionally on a NUMA distance seems like a good additional
feature, magny-core and small nehalem systems would want this
enabled, systems with slow interconnects would not.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-10 11:50:02 +00:00
|
|
|
return new_cpu;
|
2008-01-25 20:08:09 +00:00
|
|
|
}
|
2012-10-04 11:18:30 +00:00
|
|
|
|
2017-05-11 15:57:24 +00:00
|
|
|
static void detach_entity_cfs_rq(struct sched_entity *se);
|
|
|
|
|
2012-10-04 11:18:30 +00:00
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Called immediately before a task is migrated to a new CPU; task_cpu(p) and
|
2012-10-04 11:18:30 +00:00
|
|
|
* cfs_rq_of(p) references at time of call are still valid and identify the
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* previous CPU. The caller guarantees p->pi_lock or task_rq(p)->lock is held.
|
2012-10-04 11:18:30 +00:00
|
|
|
*/
|
sched/numa: Reset scan rate whenever task moves across nodes
Currently task scan rate is reset when NUMA balancer migrates the task
to a different node. If NUMA balancer initiates a swap, reset is only
applicable to the task that initiates the swap. Similarly no scan rate
reset is done if the task is migrated across nodes by traditional load
balancer.
Instead move the scan reset to the migrate_task_rq. This ensures the
task moved out of its preferred node, either gets back to its preferred
node quickly or finds a new preferred node. Doing so, would be fair to
all tasks migrating across nodes.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200668 203370 1.3465
1 321791 328431 2.06345
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 204848 206070 0.59654
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 188098 188386 0.153112
1 200351 201566 0.606436
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 58145.9 59157.4 1.73959
1 103798 105495 1.63491
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,912,183 13,825,492
migrations 1,155,931 1,152,509
faults 367,139 371,948
cache-misses 54,240,196,814 55,654,206,041
sched:sched_move_numa 1,571 1,856
sched:sched_stick_numa 9 4
sched:sched_swap_numa 463 428
migrate:mm_migrate_pages 703 898
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 50155 57146
numa_hint_faults_local 45264 51612
numa_hit 239652 238164
numa_huge_pte_updates 36 16
numa_interleave 68 63
numa_local 239576 238085
numa_other 76 79
numa_pages_migrated 680 883
numa_pte_updates 71146 67540
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,156,720 3,288,525
migrations 30,354 38,652
faults 97,261 111,678
cache-misses 12,400,026,826 12,111,197,376
sched:sched_move_numa 4 900
sched:sched_stick_numa 0 0
sched:sched_swap_numa 1 5
migrate:mm_migrate_pages 20 714
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 272 18572
numa_hint_faults_local 186 14850
numa_hit 71362 73197
numa_huge_pte_updates 0 11
numa_interleave 23 25
numa_local 71299 73138
numa_other 63 59
numa_pages_migrated 2 712
numa_pte_updates 0 24021
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,606,824 8,451,543
migrations 155,352 202,804
faults 301,409 310,024
cache-misses 157,759,224 253,522,507
sched:sched_move_numa 168 213
sched:sched_stick_numa 0 0
sched:sched_swap_numa 3 2
migrate:mm_migrate_pages 125 88
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 4650 11830
numa_hint_faults_local 3946 11301
numa_hit 90489 90038
numa_huge_pte_updates 0 0
numa_interleave 892 855
numa_local 90034 89796
numa_other 455 242
numa_pages_migrated 124 88
numa_pte_updates 4818 12039
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,113,167 2,049,153
migrations 10,533 11,405
faults 142,727 162,309
cache-misses 5,594,192 7,203,343
sched:sched_move_numa 10 22
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 6 1
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 744 1693
numa_hint_faults_local 584 1669
numa_hit 25551 25177
numa_huge_pte_updates 0 0
numa_interleave 263 194
numa_local 25302 24993
numa_other 249 184
numa_pages_migrated 6 1
numa_pte_updates 744 1577
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 101,227,352 94,515,937
migrations 4,151,829 4,203,554
faults 745,233 832,697
cache-misses 224,669,561,766 226,248,698,331
sched:sched_move_numa 617 1,730
sched:sched_stick_numa 2 14
sched:sched_swap_numa 187 432
migrate:mm_migrate_pages 316 1,398
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 24195 80079
numa_hint_faults_local 21639 68620
numa_hit 238331 241187
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 238331 241186
numa_other 0 1
numa_pages_migrated 204 1347
numa_pte_updates 24561 80729
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 62,738,978 63,704,961
migrations 562,702 573,404
faults 228,465 230,878
cache-misses 75,778,067,952 76,568,222,781
sched:sched_move_numa 648 509
sched:sched_stick_numa 13 31
sched:sched_swap_numa 137 182
migrate:mm_migrate_pages 733 541
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 10281 8501
numa_hint_faults_local 3242 2960
numa_hit 36338 35526
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 36338 35526
numa_other 0 0
numa_pages_migrated 706 539
numa_pte_updates 10176 8433
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-4-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:58 +00:00
|
|
|
static void migrate_task_rq_fair(struct task_struct *p, int new_cpu)
|
2012-10-04 11:18:30 +00:00
|
|
|
{
|
2016-05-10 16:24:37 +00:00
|
|
|
/*
|
|
|
|
* As blocked tasks retain absolute vruntime the migration needs to
|
|
|
|
* deal with this by subtracting the old and adding the new
|
|
|
|
* min_vruntime -- the latter is done by enqueue_entity() when placing
|
|
|
|
* the task on the new runqueue.
|
|
|
|
*/
|
|
|
|
if (p->state == TASK_WAKING) {
|
|
|
|
struct sched_entity *se = &p->se;
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
|
|
|
u64 min_vruntime;
|
|
|
|
|
|
|
|
#ifndef CONFIG_64BIT
|
|
|
|
u64 min_vruntime_copy;
|
|
|
|
|
|
|
|
do {
|
|
|
|
min_vruntime_copy = cfs_rq->min_vruntime_copy;
|
|
|
|
smp_rmb();
|
|
|
|
min_vruntime = cfs_rq->min_vruntime;
|
|
|
|
} while (min_vruntime != min_vruntime_copy);
|
|
|
|
#else
|
|
|
|
min_vruntime = cfs_rq->min_vruntime;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
se->vruntime -= min_vruntime;
|
|
|
|
}
|
|
|
|
|
2017-05-11 15:57:24 +00:00
|
|
|
if (p->on_rq == TASK_ON_RQ_MIGRATING) {
|
|
|
|
/*
|
|
|
|
* In case of TASK_ON_RQ_MIGRATING we in fact hold the 'old'
|
|
|
|
* rq->lock and can modify state directly.
|
|
|
|
*/
|
|
|
|
lockdep_assert_held(&task_rq(p)->lock);
|
|
|
|
detach_entity_cfs_rq(&p->se);
|
|
|
|
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* We are supposed to update the task to "current" time, then
|
|
|
|
* its up to date and ready to go to new CPU/cfs_rq. But we
|
|
|
|
* have difficulty in getting what current time is, so simply
|
|
|
|
* throw away the out-of-date time. This will result in the
|
|
|
|
* wakee task is less decayed, but giving the wakee more load
|
|
|
|
* sounds not bad.
|
|
|
|
*/
|
|
|
|
remove_entity_load_avg(&p->se);
|
|
|
|
}
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
|
|
|
|
/* Tell new CPU we are migrated */
|
|
|
|
p->se.avg.last_update_time = 0;
|
2014-05-15 22:59:20 +00:00
|
|
|
|
|
|
|
/* We have migrated, no longer consider this task hot */
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
p->se.exec_start = 0;
|
sched/numa: Reset scan rate whenever task moves across nodes
Currently task scan rate is reset when NUMA balancer migrates the task
to a different node. If NUMA balancer initiates a swap, reset is only
applicable to the task that initiates the swap. Similarly no scan rate
reset is done if the task is migrated across nodes by traditional load
balancer.
Instead move the scan reset to the migrate_task_rq. This ensures the
task moved out of its preferred node, either gets back to its preferred
node quickly or finds a new preferred node. Doing so, would be fair to
all tasks migrating across nodes.
Specjbb2005 results (8 warehouses)
Higher bops are better
2 Socket - 2 Node Haswell - X86
JVMS Prev Current %Change
4 200668 203370 1.3465
1 321791 328431 2.06345
2 Socket - 4 Node Power8 - PowerNV
JVMS Prev Current %Change
1 204848 206070 0.59654
2 Socket - 2 Node Power9 - PowerNV
JVMS Prev Current %Change
4 188098 188386 0.153112
1 200351 201566 0.606436
4 Socket - 4 Node Power7 - PowerVM
JVMS Prev Current %Change
8 58145.9 59157.4 1.73959
1 103798 105495 1.63491
Some events stats before and after applying the patch.
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 13,912,183 13,825,492
migrations 1,155,931 1,152,509
faults 367,139 371,948
cache-misses 54,240,196,814 55,654,206,041
sched:sched_move_numa 1,571 1,856
sched:sched_stick_numa 9 4
sched:sched_swap_numa 463 428
migrate:mm_migrate_pages 703 898
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 50155 57146
numa_hint_faults_local 45264 51612
numa_hit 239652 238164
numa_huge_pte_updates 36 16
numa_interleave 68 63
numa_local 239576 238085
numa_other 76 79
numa_pages_migrated 680 883
numa_pte_updates 71146 67540
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
cs 3,156,720 3,288,525
migrations 30,354 38,652
faults 97,261 111,678
cache-misses 12,400,026,826 12,111,197,376
sched:sched_move_numa 4 900
sched:sched_stick_numa 0 0
sched:sched_swap_numa 1 5
migrate:mm_migrate_pages 20 714
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Haswell - X86
Event Before After
numa_hint_faults 272 18572
numa_hint_faults_local 186 14850
numa_hit 71362 73197
numa_huge_pte_updates 0 11
numa_interleave 23 25
numa_local 71299 73138
numa_other 63 59
numa_pages_migrated 2 712
numa_pte_updates 0 24021
perf stats 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 8,606,824 8,451,543
migrations 155,352 202,804
faults 301,409 310,024
cache-misses 157,759,224 253,522,507
sched:sched_move_numa 168 213
sched:sched_stick_numa 0 0
sched:sched_swap_numa 3 2
migrate:mm_migrate_pages 125 88
vmstat 8th warehouse Multi JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 4650 11830
numa_hint_faults_local 3946 11301
numa_hit 90489 90038
numa_huge_pte_updates 0 0
numa_interleave 892 855
numa_local 90034 89796
numa_other 455 242
numa_pages_migrated 124 88
numa_pte_updates 4818 12039
perf stats 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
cs 2,113,167 2,049,153
migrations 10,533 11,405
faults 142,727 162,309
cache-misses 5,594,192 7,203,343
sched:sched_move_numa 10 22
sched:sched_stick_numa 0 0
sched:sched_swap_numa 0 0
migrate:mm_migrate_pages 6 1
vmstat 8th warehouse Single JVM 2 Socket - 2 Node Power9 - PowerNV
Event Before After
numa_hint_faults 744 1693
numa_hint_faults_local 584 1669
numa_hit 25551 25177
numa_huge_pte_updates 0 0
numa_interleave 263 194
numa_local 25302 24993
numa_other 249 184
numa_pages_migrated 6 1
numa_pte_updates 744 1577
perf stats 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 101,227,352 94,515,937
migrations 4,151,829 4,203,554
faults 745,233 832,697
cache-misses 224,669,561,766 226,248,698,331
sched:sched_move_numa 617 1,730
sched:sched_stick_numa 2 14
sched:sched_swap_numa 187 432
migrate:mm_migrate_pages 316 1,398
vmstat 8th warehouse Multi JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 24195 80079
numa_hint_faults_local 21639 68620
numa_hit 238331 241187
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 238331 241186
numa_other 0 1
numa_pages_migrated 204 1347
numa_pte_updates 24561 80729
perf stats 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
cs 62,738,978 63,704,961
migrations 562,702 573,404
faults 228,465 230,878
cache-misses 75,778,067,952 76,568,222,781
sched:sched_move_numa 648 509
sched:sched_stick_numa 13 31
sched:sched_swap_numa 137 182
migrate:mm_migrate_pages 733 541
vmstat 8th warehouse Single JVM 4 Socket - 4 Node Power7 - PowerVM
Event Before After
numa_hint_faults 10281 8501
numa_hint_faults_local 3242 2960
numa_hit 36338 35526
numa_huge_pte_updates 0 0
numa_interleave 0 0
numa_local 36338 35526
numa_other 0 0
numa_pages_migrated 706 539
numa_pte_updates 10176 8433
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Jirka Hladky <jhladky@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1537552141-27815-4-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-21 17:48:58 +00:00
|
|
|
|
|
|
|
update_scan_period(p, new_cpu);
|
2012-10-04 11:18:30 +00:00
|
|
|
}
|
2015-07-15 00:04:40 +00:00
|
|
|
|
|
|
|
static void task_dead_fair(struct task_struct *p)
|
|
|
|
{
|
|
|
|
remove_entity_load_avg(&p->se);
|
|
|
|
}
|
2019-11-08 10:11:52 +00:00
|
|
|
|
|
|
|
static int
|
|
|
|
balance_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
|
|
|
|
{
|
|
|
|
if (rq->nr_running)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return newidle_balance(rq, rf) != 0;
|
|
|
|
}
|
2008-01-25 20:08:09 +00:00
|
|
|
#endif /* CONFIG_SMP */
|
|
|
|
|
2017-12-07 13:30:43 +00:00
|
|
|
static unsigned long wakeup_gran(struct sched_entity *se)
|
2008-04-19 17:44:57 +00:00
|
|
|
{
|
|
|
|
unsigned long gran = sysctl_sched_wakeup_granularity;
|
|
|
|
|
|
|
|
/*
|
2009-01-14 11:39:19 +00:00
|
|
|
* Since its curr running now, convert the gran from real-time
|
|
|
|
* to virtual-time in his units.
|
2010-03-11 16:17:04 +00:00
|
|
|
*
|
|
|
|
* By using 'se' instead of 'curr' we penalize light tasks, so
|
|
|
|
* they get preempted easier. That is, if 'se' < 'curr' then
|
|
|
|
* the resulting gran will be larger, therefore penalizing the
|
|
|
|
* lighter, if otoh 'se' > 'curr' then the resulting gran will
|
|
|
|
* be smaller, again penalizing the lighter task.
|
|
|
|
*
|
|
|
|
* This is especially important for buddies when the leftmost
|
|
|
|
* task is higher priority than the buddy.
|
2008-04-19 17:44:57 +00:00
|
|
|
*/
|
2011-04-08 04:53:09 +00:00
|
|
|
return calc_delta_fair(gran, se);
|
2008-04-19 17:44:57 +00:00
|
|
|
}
|
|
|
|
|
2008-10-24 09:06:15 +00:00
|
|
|
/*
|
|
|
|
* Should 'se' preempt 'curr'.
|
|
|
|
*
|
|
|
|
* |s1
|
|
|
|
* |s2
|
|
|
|
* |s3
|
|
|
|
* g
|
|
|
|
* |<--->|c
|
|
|
|
*
|
|
|
|
* w(c, s1) = -1
|
|
|
|
* w(c, s2) = 0
|
|
|
|
* w(c, s3) = 1
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
wakeup_preempt_entity(struct sched_entity *curr, struct sched_entity *se)
|
|
|
|
{
|
|
|
|
s64 gran, vdiff = curr->vruntime - se->vruntime;
|
|
|
|
|
|
|
|
if (vdiff <= 0)
|
|
|
|
return -1;
|
|
|
|
|
2017-12-07 13:30:43 +00:00
|
|
|
gran = wakeup_gran(se);
|
2008-10-24 09:06:15 +00:00
|
|
|
if (vdiff > gran)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-11-04 20:25:10 +00:00
|
|
|
static void set_last_buddy(struct sched_entity *se)
|
|
|
|
{
|
2018-11-05 11:21:55 +00:00
|
|
|
if (entity_is_task(se) && unlikely(task_has_idle_policy(task_of(se))))
|
2011-04-14 01:21:09 +00:00
|
|
|
return;
|
|
|
|
|
2017-05-10 20:11:39 +00:00
|
|
|
for_each_sched_entity(se) {
|
|
|
|
if (SCHED_WARN_ON(!se->on_rq))
|
|
|
|
return;
|
2011-04-14 01:21:09 +00:00
|
|
|
cfs_rq_of(se)->last = se;
|
2017-05-10 20:11:39 +00:00
|
|
|
}
|
2008-11-04 20:25:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void set_next_buddy(struct sched_entity *se)
|
|
|
|
{
|
2018-11-05 11:21:55 +00:00
|
|
|
if (entity_is_task(se) && unlikely(task_has_idle_policy(task_of(se))))
|
2011-04-14 01:21:09 +00:00
|
|
|
return;
|
|
|
|
|
2017-05-10 20:11:39 +00:00
|
|
|
for_each_sched_entity(se) {
|
|
|
|
if (SCHED_WARN_ON(!se->on_rq))
|
|
|
|
return;
|
2011-04-14 01:21:09 +00:00
|
|
|
cfs_rq_of(se)->next = se;
|
2017-05-10 20:11:39 +00:00
|
|
|
}
|
2008-11-04 20:25:10 +00:00
|
|
|
}
|
|
|
|
|
2011-02-01 14:51:03 +00:00
|
|
|
static void set_skip_buddy(struct sched_entity *se)
|
|
|
|
{
|
2011-04-14 01:21:09 +00:00
|
|
|
for_each_sched_entity(se)
|
|
|
|
cfs_rq_of(se)->skip = se;
|
2011-02-01 14:51:03 +00:00
|
|
|
}
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* Preempt the current task with a newly woken task if needed:
|
|
|
|
*/
|
2009-09-16 11:47:58 +00:00
|
|
|
static void check_preempt_wakeup(struct rq *rq, struct task_struct *p, int wake_flags)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
|
|
|
struct task_struct *curr = rq->curr;
|
2007-10-15 15:00:12 +00:00
|
|
|
struct sched_entity *se = &curr->se, *pse = &p->se;
|
2008-12-16 07:45:30 +00:00
|
|
|
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
|
sched: Strengthen buddies and mitigate buddy induced latencies
This patch restores the effectiveness of LAST_BUDDY in preventing
pgsql+oltp from collapsing due to wakeup preemption. It also
switches LAST_BUDDY to exclusively do what it does best, namely
mitigate the effects of aggressive wakeup preemption, which
improves vmark throughput markedly, and restores mysql+oltp
scalability.
Since buddies are about scalability, enable them beginning at the
point where we begin expanding sched_latency, namely
sched_nr_latency. Previously, buddies were cleared aggressively,
which seriously reduced their effectiveness. Not clearing
aggressively however, produces a small drop in mysql+oltp
throughput immediately after peak, indicating that LAST_BUDDY is
actually doing some harm. This is right at the point where X on the
desktop in competition with another load wants low latency service.
Ergo, do not enable until we need to scale.
To mitigate latency induced by buddies, or by a task just missing
wakeup preemption, check latency at tick time.
Last hunk prevents buddies from stymieing BALANCE_NEWIDLE via
CACHE_HOT_BUDDY.
Supporting performance tests:
tip = v2.6.32-rc5-1497-ga525b32
tipx = NO_GENTLE_FAIR_SLEEPERS NEXT_BUDDY granularity knobs = 31 knobs + 31 buddies
tip+x = NO_GENTLE_FAIR_SLEEPERS granularity knobs = 31 knobs
(Three run averages except where noted.)
vmark:
------
tip 108466 messages per second
tip+ 125307 messages per second
tip+x 125335 messages per second
tipx 117781 messages per second
2.6.31.3 122729 messages per second
mysql+oltp:
-----------
clients 1 2 4 8 16 32 64 128 256
..........................................................................................
tip 9949.89 18690.20 34801.24 34460.04 32682.88 30765.97 28305.27 25059.64 19548.08
tip+ 10013.90 18526.84 34900.38 34420.14 33069.83 32083.40 30578.30 28010.71 25605.47
tipx 9698.71 18002.70 34477.56 33420.01 32634.30 31657.27 29932.67 26827.52 21487.18
2.6.31.3 8243.11 18784.20 34404.83 33148.38 31900.32 31161.90 29663.81 25995.94 18058.86
pgsql+oltp:
-----------
clients 1 2 4 8 16 32 64 128 256
..........................................................................................
tip 13686.37 26609.25 51934.28 51347.81 49479.51 45312.65 36691.91 26851.57 24145.35
tip+ (1x) 13907.85 27135.87 52951.98 52514.04 51742.52 50705.43 49947.97 48374.19 46227.94
tip+x 13906.78 27065.81 52951.19 52542.59 52176.11 51815.94 50838.90 49439.46 46891.00
tipx 13742.46 26769.81 52351.99 51891.73 51320.79 50938.98 50248.65 48908.70 46553.84
2.6.31.3 13815.35 26906.46 52683.34 52061.31 51937.10 51376.80 50474.28 49394.47 47003.25
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-10-23 21:09:22 +00:00
|
|
|
int scale = cfs_rq->nr_running >= sched_nr_latency;
|
2011-04-14 17:30:53 +00:00
|
|
|
int next_buddy_marked = 0;
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2008-03-19 00:42:00 +00:00
|
|
|
if (unlikely(se == pse))
|
|
|
|
return;
|
|
|
|
|
2011-07-21 16:43:37 +00:00
|
|
|
/*
|
2014-08-20 09:48:29 +00:00
|
|
|
* This is possible from callers such as attach_tasks(), in which we
|
2011-07-21 16:43:37 +00:00
|
|
|
* unconditionally check_prempt_curr() after an enqueue (which may have
|
|
|
|
* lead to a throttle). This both saves work and prevents false
|
|
|
|
* next-buddy nomination below.
|
|
|
|
*/
|
|
|
|
if (unlikely(throttled_hierarchy(cfs_rq_of(pse))))
|
|
|
|
return;
|
|
|
|
|
2011-04-14 17:30:53 +00:00
|
|
|
if (sched_feat(NEXT_BUDDY) && scale && !(wake_flags & WF_FORK)) {
|
2009-09-11 10:01:17 +00:00
|
|
|
set_next_buddy(pse);
|
2011-04-14 17:30:53 +00:00
|
|
|
next_buddy_marked = 1;
|
|
|
|
}
|
2008-09-23 13:33:45 +00:00
|
|
|
|
2008-08-28 09:12:49 +00:00
|
|
|
/*
|
|
|
|
* We can come here with TIF_NEED_RESCHED already set from new task
|
|
|
|
* wake up path.
|
2011-07-21 16:43:37 +00:00
|
|
|
*
|
|
|
|
* Note: this also catches the edge-case of curr being in a throttled
|
|
|
|
* group (e.g. via set_curr_task), since update_curr() (in the
|
|
|
|
* enqueue of curr) will have resulted in resched being set. This
|
|
|
|
* prevents us from potentially nominating it as a false LAST_BUDDY
|
|
|
|
* below.
|
2008-08-28 09:12:49 +00:00
|
|
|
*/
|
|
|
|
if (test_tsk_need_resched(curr))
|
|
|
|
return;
|
|
|
|
|
2011-02-22 21:04:33 +00:00
|
|
|
/* Idle tasks are by definition preempted by non-idle tasks. */
|
2018-11-05 11:21:55 +00:00
|
|
|
if (unlikely(task_has_idle_policy(curr)) &&
|
|
|
|
likely(!task_has_idle_policy(p)))
|
2011-02-22 21:04:33 +00:00
|
|
|
goto preempt;
|
|
|
|
|
2007-10-15 15:00:18 +00:00
|
|
|
/*
|
2011-02-22 21:04:33 +00:00
|
|
|
* Batch and idle tasks do not preempt non-idle tasks (their preemption
|
|
|
|
* is driven by the tick):
|
2007-10-15 15:00:18 +00:00
|
|
|
*/
|
2012-10-14 12:28:50 +00:00
|
|
|
if (unlikely(p->policy != SCHED_NORMAL) || !sched_feat(WAKEUP_PREEMPTION))
|
2007-10-15 15:00:18 +00:00
|
|
|
return;
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2008-10-24 09:06:15 +00:00
|
|
|
find_matching_se(&se, &pse);
|
2011-07-06 02:07:21 +00:00
|
|
|
update_curr(cfs_rq_of(se));
|
2009-04-08 22:29:43 +00:00
|
|
|
BUG_ON(!pse);
|
2011-04-14 17:30:53 +00:00
|
|
|
if (wakeup_preempt_entity(se, pse) == 1) {
|
|
|
|
/*
|
|
|
|
* Bias pick_next to pick the sched entity that is
|
|
|
|
* triggering this preemption.
|
|
|
|
*/
|
|
|
|
if (!next_buddy_marked)
|
|
|
|
set_next_buddy(pse);
|
2009-11-28 17:51:02 +00:00
|
|
|
goto preempt;
|
2011-04-14 17:30:53 +00:00
|
|
|
}
|
2008-10-24 09:06:15 +00:00
|
|
|
|
2009-11-28 17:51:02 +00:00
|
|
|
return;
|
2009-11-17 09:51:40 +00:00
|
|
|
|
2009-11-28 17:51:02 +00:00
|
|
|
preempt:
|
2014-06-28 20:03:57 +00:00
|
|
|
resched_curr(rq);
|
2009-11-28 17:51:02 +00:00
|
|
|
/*
|
|
|
|
* Only set the backward buddy when the current task is still
|
|
|
|
* on the rq. This can happen when a wakeup gets interleaved
|
|
|
|
* with schedule on the ->pre_schedule() or idle_balance()
|
|
|
|
* point, either of which can * drop the rq lock.
|
|
|
|
*
|
|
|
|
* Also, during early boot the idle thread is in the fair class,
|
|
|
|
* for obvious reasons its a bad idea to schedule back to it.
|
|
|
|
*/
|
|
|
|
if (unlikely(!se->on_rq || curr == rq->idle))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (sched_feat(LAST_BUDDY) && scale && entity_is_task(se))
|
|
|
|
set_last_buddy(se);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2019-11-08 13:15:57 +00:00
|
|
|
struct task_struct *
|
2016-09-21 13:38:10 +00:00
|
|
|
pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq = &rq->cfs;
|
|
|
|
struct sched_entity *se;
|
2012-02-11 05:05:00 +00:00
|
|
|
struct task_struct *p;
|
2014-02-14 11:25:08 +00:00
|
|
|
int new_tasks;
|
2012-02-11 05:05:00 +00:00
|
|
|
|
2014-02-11 15:11:48 +00:00
|
|
|
again:
|
2019-11-08 10:11:52 +00:00
|
|
|
if (!sched_fair_runnable(rq))
|
2014-01-23 19:32:21 +00:00
|
|
|
goto idle;
|
2012-02-11 05:05:00 +00:00
|
|
|
|
2017-05-24 05:29:55 +00:00
|
|
|
#ifdef CONFIG_FAIR_GROUP_SCHED
|
2019-05-29 20:36:44 +00:00
|
|
|
if (!prev || prev->sched_class != &fair_sched_class)
|
2012-02-11 05:05:00 +00:00
|
|
|
goto simple;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Because of the set_next_buddy() in dequeue_task_fair() it is rather
|
|
|
|
* likely that a next task is from the same cgroup as the current.
|
|
|
|
*
|
|
|
|
* Therefore attempt to avoid putting and setting the entire cgroup
|
|
|
|
* hierarchy, only change the part that actually changes.
|
|
|
|
*/
|
|
|
|
|
|
|
|
do {
|
|
|
|
struct sched_entity *curr = cfs_rq->curr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since we got here without doing put_prev_entity() we also
|
|
|
|
* have to consider cfs_rq->curr. If it is still a runnable
|
|
|
|
* entity, update_curr() will update its vruntime, otherwise
|
|
|
|
* forget we've ever seen it.
|
|
|
|
*/
|
2015-04-06 22:28:10 +00:00
|
|
|
if (curr) {
|
|
|
|
if (curr->on_rq)
|
|
|
|
update_curr(cfs_rq);
|
|
|
|
else
|
|
|
|
curr = NULL;
|
2012-02-11 05:05:00 +00:00
|
|
|
|
2015-04-06 22:28:10 +00:00
|
|
|
/*
|
|
|
|
* This call to check_cfs_rq_runtime() will do the
|
|
|
|
* throttle and dequeue its entity in the parent(s).
|
2017-05-24 05:29:55 +00:00
|
|
|
* Therefore the nr_running test will indeed
|
2015-04-06 22:28:10 +00:00
|
|
|
* be correct.
|
|
|
|
*/
|
2017-05-24 05:29:55 +00:00
|
|
|
if (unlikely(check_cfs_rq_runtime(cfs_rq))) {
|
|
|
|
cfs_rq = &rq->cfs;
|
|
|
|
|
|
|
|
if (!cfs_rq->nr_running)
|
|
|
|
goto idle;
|
|
|
|
|
2015-04-06 22:28:10 +00:00
|
|
|
goto simple;
|
2017-05-24 05:29:55 +00:00
|
|
|
}
|
2015-04-06 22:28:10 +00:00
|
|
|
}
|
2012-02-11 05:05:00 +00:00
|
|
|
|
|
|
|
se = pick_next_entity(cfs_rq, curr);
|
|
|
|
cfs_rq = group_cfs_rq(se);
|
|
|
|
} while (cfs_rq);
|
|
|
|
|
|
|
|
p = task_of(se);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since we haven't yet done put_prev_entity and if the selected task
|
|
|
|
* is a different task than we started out with, try and touch the
|
|
|
|
* least amount of cfs_rqs.
|
|
|
|
*/
|
|
|
|
if (prev != p) {
|
|
|
|
struct sched_entity *pse = &prev->se;
|
|
|
|
|
|
|
|
while (!(cfs_rq = is_same_group(se, pse))) {
|
|
|
|
int se_depth = se->depth;
|
|
|
|
int pse_depth = pse->depth;
|
|
|
|
|
|
|
|
if (se_depth <= pse_depth) {
|
|
|
|
put_prev_entity(cfs_rq_of(pse), pse);
|
|
|
|
pse = parent_entity(pse);
|
|
|
|
}
|
|
|
|
if (se_depth >= pse_depth) {
|
|
|
|
set_next_entity(cfs_rq_of(se), se);
|
|
|
|
se = parent_entity(se);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
put_prev_entity(cfs_rq, pse);
|
|
|
|
set_next_entity(cfs_rq, se);
|
|
|
|
}
|
|
|
|
|
2017-09-13 10:24:30 +00:00
|
|
|
goto done;
|
2012-02-11 05:05:00 +00:00
|
|
|
simple:
|
|
|
|
#endif
|
2019-05-29 20:36:44 +00:00
|
|
|
if (prev)
|
|
|
|
put_prev_task(rq, prev);
|
2012-02-11 05:05:00 +00:00
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
do {
|
2012-02-11 05:05:00 +00:00
|
|
|
se = pick_next_entity(cfs_rq, NULL);
|
2008-11-04 20:25:07 +00:00
|
|
|
set_next_entity(cfs_rq, se);
|
2007-07-09 16:51:58 +00:00
|
|
|
cfs_rq = group_cfs_rq(se);
|
|
|
|
} while (cfs_rq);
|
|
|
|
|
2008-01-25 20:08:29 +00:00
|
|
|
p = task_of(se);
|
2012-02-11 05:05:00 +00:00
|
|
|
|
2018-02-27 07:47:40 +00:00
|
|
|
done: __maybe_unused;
|
2017-09-13 10:24:30 +00:00
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
/*
|
|
|
|
* Move the next running task to the front of
|
|
|
|
* the list, so our cfs_tasks list becomes MRU
|
|
|
|
* one.
|
|
|
|
*/
|
|
|
|
list_move(&p->se.group_node, &rq->cfs_tasks);
|
|
|
|
#endif
|
|
|
|
|
2011-11-22 14:20:07 +00:00
|
|
|
if (hrtick_enabled(rq))
|
|
|
|
hrtick_start_fair(rq, p);
|
2008-01-25 20:08:29 +00:00
|
|
|
|
2018-07-04 10:17:40 +00:00
|
|
|
update_misfit_status(p, rq);
|
|
|
|
|
2008-01-25 20:08:29 +00:00
|
|
|
return p;
|
2014-01-23 19:32:21 +00:00
|
|
|
|
|
|
|
idle:
|
2019-05-29 20:36:44 +00:00
|
|
|
if (!rf)
|
|
|
|
return NULL;
|
|
|
|
|
2019-05-29 20:36:42 +00:00
|
|
|
new_tasks = newidle_balance(rq, rf);
|
2016-09-21 13:38:12 +00:00
|
|
|
|
2014-02-14 11:25:08 +00:00
|
|
|
/*
|
2019-05-29 20:36:42 +00:00
|
|
|
* Because newidle_balance() releases (and re-acquires) rq->lock, it is
|
2014-02-14 11:25:08 +00:00
|
|
|
* possible for any higher priority task to appear. In that case we
|
|
|
|
* must re-start the pick_next_entity() loop.
|
|
|
|
*/
|
2014-03-06 09:31:55 +00:00
|
|
|
if (new_tasks < 0)
|
2014-02-14 11:25:08 +00:00
|
|
|
return RETRY_TASK;
|
|
|
|
|
2014-03-06 09:31:55 +00:00
|
|
|
if (new_tasks > 0)
|
2014-01-23 19:32:21 +00:00
|
|
|
goto again;
|
|
|
|
|
sched/fair: Update scale invariance of PELT
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not invariant because not scaled with uarch.
The util_avg of a periodic task that runs r time slots every p time slots
varies in the range :
U * (1-y^r)/(1-y^p) * y^i < Utilization < U * (1-y^r)/(1-y^p)
with U is the max util_avg value = SCHED_CAPACITY_SCALE
At a lower capacity, the range becomes:
U * C * (1-y^r')/(1-y^p) * y^i' < Utilization < U * C * (1-y^r')/(1-y^p)
with C reflecting the compute capacity ratio between current capacity and
max capacity.
so C tries to compensate changes in (1-y^r') but it can't be accurate.
Instead of scaling the contribution value of PELT algo, we should scale the
running time. The PELT signal aims to track the amount of computation of
tasks and/or rq so it seems more correct to scale the running time to
reflect the effective amount of computation done since the last update.
In order to be fully invariant, we need to apply the same amount of
running time and idle time whatever the current capacity. Because running
at lower capacity implies that the task will run longer, we have to ensure
that the same amount of idle time will be applied when system becomes idle
and no idle time has been "stolen". But reaching the maximum utilization
value (SCHED_CAPACITY_SCALE) means that the task is seen as an
always-running task whatever the capacity of the CPU (even at max compute
capacity). In this case, we can discard this "stolen" idle times which
becomes meaningless.
In order to achieve this time scaling, a new clock_pelt is created per rq.
The increase of this clock scales with current capacity when something
is running on rq and synchronizes with clock_task when rq is idle. With
this mechanism, we ensure the same running and idle time whatever the
current capacity. This also enables to simplify the pelt algorithm by
removing all references of uarch and frequency and applying the same
contribution to utilization and loads. Furthermore, the scaling is done
only once per update of clock (update_rq_clock_task()) instead of during
each update of sched_entities and cfs/rt/dl_rq of the rq like the current
implementation. This is interesting when cgroup are involved as shown in
the results below:
On a hikey (octo Arm64 platform).
Performance cpufreq governor and only shallowest c-state to remove variance
generated by those power features so we only track the impact of pelt algo.
each test runs 16 times:
./perf bench sched pipe
(higher is better)
kernel tip/sched/core + patch
ops/seconds ops/seconds diff
cgroup
root 59652(+/- 0.18%) 59876(+/- 0.24%) +0.38%
level1 55608(+/- 0.27%) 55923(+/- 0.24%) +0.57%
level2 52115(+/- 0.29%) 52564(+/- 0.22%) +0.86%
hackbench -l 1000
(lower is better)
kernel tip/sched/core + patch
duration(sec) duration(sec) diff
cgroup
root 4.453(+/- 2.37%) 4.383(+/- 2.88%) -1.57%
level1 4.859(+/- 8.50%) 4.830(+/- 7.07%) -0.60%
level2 5.063(+/- 9.83%) 4.928(+/- 9.66%) -2.66%
Then, the responsiveness of PELT is improved when CPU is not running at max
capacity with this new algorithm. I have put below some examples of
duration to reach some typical load values according to the capacity of the
CPU with current implementation and with this patch. These values has been
computed based on the geometric series and the half period value:
Util (%) max capacity half capacity(mainline) half capacity(w/ patch)
972 (95%) 138ms not reachable 276ms
486 (47.5%) 30ms 138ms 60ms
256 (25%) 13ms 32ms 26ms
On my hikey (octo Arm64 platform) with schedutil governor, the time to
reach max OPP when starting from a null utilization, decreases from 223ms
with current scale invariance down to 121ms with the new algorithm.
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Morten.Rasmussen@arm.com
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: patrick.bellasi@arm.com
Cc: pjt@google.com
Cc: pkondeti@codeaurora.org
Cc: quentin.perret@arm.com
Cc: rjw@rjwysocki.net
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Link: https://lkml.kernel.org/r/1548257214-13745-3-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-01-23 15:26:53 +00:00
|
|
|
/*
|
|
|
|
* rq is about to be idle, check if we need to update the
|
|
|
|
* lost_idle_time of clock_pelt
|
|
|
|
*/
|
|
|
|
update_idle_rq_clock_pelt(rq);
|
|
|
|
|
2014-01-23 19:32:21 +00:00
|
|
|
return NULL;
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2019-11-08 13:15:58 +00:00
|
|
|
static struct task_struct *__pick_next_task_fair(struct rq *rq)
|
|
|
|
{
|
|
|
|
return pick_next_task_fair(rq, NULL, NULL);
|
|
|
|
}
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* Account for a descheduled task:
|
|
|
|
*/
|
2019-11-08 10:11:52 +00:00
|
|
|
static void put_prev_task_fair(struct rq *rq, struct task_struct *prev)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
|
|
|
struct sched_entity *se = &prev->se;
|
|
|
|
struct cfs_rq *cfs_rq;
|
|
|
|
|
|
|
|
for_each_sched_entity(se) {
|
|
|
|
cfs_rq = cfs_rq_of(se);
|
2007-08-09 09:16:48 +00:00
|
|
|
put_prev_entity(cfs_rq, se);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-02-01 14:51:03 +00:00
|
|
|
/*
|
|
|
|
* sched_yield() is very simple
|
|
|
|
*
|
|
|
|
* The magic of dealing with the ->skip buddy is in pick_next_entity.
|
|
|
|
*/
|
|
|
|
static void yield_task_fair(struct rq *rq)
|
|
|
|
{
|
|
|
|
struct task_struct *curr = rq->curr;
|
|
|
|
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
|
|
|
|
struct sched_entity *se = &curr->se;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Are we the only task in the tree?
|
|
|
|
*/
|
|
|
|
if (unlikely(rq->nr_running == 1))
|
|
|
|
return;
|
|
|
|
|
|
|
|
clear_buddies(cfs_rq, se);
|
|
|
|
|
|
|
|
if (curr->policy != SCHED_BATCH) {
|
|
|
|
update_rq_clock(rq);
|
|
|
|
/*
|
|
|
|
* Update run-time statistics of the 'current'.
|
|
|
|
*/
|
|
|
|
update_curr(cfs_rq);
|
2011-11-22 14:21:26 +00:00
|
|
|
/*
|
|
|
|
* Tell update_rq_clock() that we've just updated,
|
|
|
|
* so we don't do microscopic update in schedule()
|
|
|
|
* and double the fastpath cost.
|
|
|
|
*/
|
2018-04-04 16:15:39 +00:00
|
|
|
rq_clock_skip_update(rq);
|
2011-02-01 14:51:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
set_skip_buddy(se);
|
|
|
|
}
|
|
|
|
|
2011-02-01 14:50:51 +00:00
|
|
|
static bool yield_to_task_fair(struct rq *rq, struct task_struct *p, bool preempt)
|
|
|
|
{
|
|
|
|
struct sched_entity *se = &p->se;
|
|
|
|
|
2011-07-21 16:43:37 +00:00
|
|
|
/* throttled hierarchies are not runnable */
|
|
|
|
if (!se->on_rq || throttled_hierarchy(cfs_rq_of(se)))
|
2011-02-01 14:50:51 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Tell the scheduler that we'd really like pse to run next. */
|
|
|
|
set_next_buddy(se);
|
|
|
|
|
|
|
|
yield_task_fair(rq);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2007-10-24 16:23:51 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2007-07-09 16:51:58 +00:00
|
|
|
/**************************************************
|
2012-07-03 11:53:26 +00:00
|
|
|
* Fair scheduling class load-balancing methods.
|
|
|
|
*
|
|
|
|
* BASICS
|
|
|
|
*
|
|
|
|
* The purpose of load-balancing is to achieve the same basic fairness the
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* per-CPU scheduler provides, namely provide a proportional amount of compute
|
2012-07-03 11:53:26 +00:00
|
|
|
* time to each task. This is expressed in the following equation:
|
|
|
|
*
|
|
|
|
* W_i,n/P_i == W_j,n/P_j for all i,j (1)
|
|
|
|
*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Where W_i,n is the n-th weight average for CPU i. The instantaneous weight
|
2012-07-03 11:53:26 +00:00
|
|
|
* W_i,0 is defined as:
|
|
|
|
*
|
|
|
|
* W_i,0 = \Sum_j w_i,j (2)
|
|
|
|
*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Where w_i,j is the weight of the j-th runnable task on CPU i. This weight
|
2016-03-29 23:07:51 +00:00
|
|
|
* is derived from the nice value as per sched_prio_to_weight[].
|
2012-07-03 11:53:26 +00:00
|
|
|
*
|
|
|
|
* The weight average is an exponential decay average of the instantaneous
|
|
|
|
* weight:
|
|
|
|
*
|
|
|
|
* W'_i,n = (2^n - 1) / 2^n * W_i,n + 1 / 2^n * W_i,0 (3)
|
|
|
|
*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* C_i is the compute capacity of CPU i, typically it is the
|
2012-07-03 11:53:26 +00:00
|
|
|
* fraction of 'recent' time available for SCHED_OTHER task execution. But it
|
|
|
|
* can also include other factors [XXX].
|
|
|
|
*
|
|
|
|
* To achieve this balance we define a measure of imbalance which follows
|
|
|
|
* directly from (1):
|
|
|
|
*
|
2014-05-26 22:19:38 +00:00
|
|
|
* imb_i,j = max{ avg(W/C), W_i/C_i } - min{ avg(W/C), W_j/C_j } (4)
|
2012-07-03 11:53:26 +00:00
|
|
|
*
|
|
|
|
* We them move tasks around to minimize the imbalance. In the continuous
|
|
|
|
* function space it is obvious this converges, in the discrete case we get
|
|
|
|
* a few fun cases generally called infeasible weight scenarios.
|
|
|
|
*
|
|
|
|
* [XXX expand on:
|
|
|
|
* - infeasible weights;
|
|
|
|
* - local vs global optima in the discrete case. ]
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* SCHED DOMAINS
|
|
|
|
*
|
|
|
|
* In order to solve the imbalance equation (4), and avoid the obvious O(n^2)
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* for all i,j solution, we create a tree of CPUs that follows the hardware
|
2012-07-03 11:53:26 +00:00
|
|
|
* topology where each level pairs two lower groups (or better). This results
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* in O(log n) layers. Furthermore we reduce the number of CPUs going up the
|
2012-07-03 11:53:26 +00:00
|
|
|
* tree to only the first of the previous level and we decrease the frequency
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* of load-balance at each level inv. proportional to the number of CPUs in
|
2012-07-03 11:53:26 +00:00
|
|
|
* the groups.
|
|
|
|
*
|
|
|
|
* This yields:
|
|
|
|
*
|
|
|
|
* log_2 n 1 n
|
|
|
|
* \Sum { --- * --- * 2^i } = O(n) (5)
|
|
|
|
* i = 0 2^i 2^i
|
|
|
|
* `- size of each group
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* | | `- number of CPUs doing load-balance
|
2012-07-03 11:53:26 +00:00
|
|
|
* | `- freq
|
|
|
|
* `- sum over all levels
|
|
|
|
*
|
|
|
|
* Coupled with a limit on how many tasks we can migrate every balance pass,
|
|
|
|
* this makes (5) the runtime complexity of the balancer.
|
|
|
|
*
|
|
|
|
* An important property here is that each CPU is still (indirectly) connected
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* to every other CPU in at most O(log n) steps:
|
2012-07-03 11:53:26 +00:00
|
|
|
*
|
|
|
|
* The adjacency matrix of the resulting graph is given by:
|
|
|
|
*
|
2015-07-05 09:33:48 +00:00
|
|
|
* log_2 n
|
2012-07-03 11:53:26 +00:00
|
|
|
* A_i,j = \Union (i % 2^k == 0) && i / 2^(k+1) == j / 2^(k+1) (6)
|
|
|
|
* k = 0
|
|
|
|
*
|
|
|
|
* And you'll find that:
|
|
|
|
*
|
|
|
|
* A^(log_2 n)_i,j != 0 for all i,j (7)
|
|
|
|
*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Showing there's indeed a path between every CPU in at most O(log n) steps.
|
2012-07-03 11:53:26 +00:00
|
|
|
* The task movement gives a factor of O(m), giving a convergence complexity
|
|
|
|
* of:
|
|
|
|
*
|
|
|
|
* O(nm log n), n := nr_cpus, m := nr_tasks (8)
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* WORK CONSERVING
|
|
|
|
*
|
|
|
|
* In order to avoid CPUs going idle while there's still work to do, new idle
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* balancing is more aggressive and has the newly idle CPU iterate up the domain
|
2012-07-03 11:53:26 +00:00
|
|
|
* tree itself instead of relying on other CPUs to bring it work.
|
|
|
|
*
|
|
|
|
* This adds some complexity to both (5) and (8) but it reduces the total idle
|
|
|
|
* time.
|
|
|
|
*
|
|
|
|
* [XXX more?]
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* CGROUPS
|
|
|
|
*
|
|
|
|
* Cgroups make a horror show out of (2), instead of a simple sum we get:
|
|
|
|
*
|
|
|
|
* s_k,i
|
|
|
|
* W_i,0 = \Sum_j \Prod_k w_k * ----- (9)
|
|
|
|
* S_k
|
|
|
|
*
|
|
|
|
* Where
|
|
|
|
*
|
|
|
|
* s_k,i = \Sum_j w_i,j,k and S_k = \Sum_i s_k,i (10)
|
|
|
|
*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* w_i,j,k is the weight of the j-th runnable task in the k-th cgroup on CPU i.
|
2012-07-03 11:53:26 +00:00
|
|
|
*
|
|
|
|
* The big problem is S_k, its a global sum needed to compute a local (W_i)
|
|
|
|
* property.
|
|
|
|
*
|
|
|
|
* [XXX write more on how we solve this.. _after_ merging pjt's patches that
|
|
|
|
* rewrite all of this once again.]
|
2015-07-05 09:33:48 +00:00
|
|
|
*/
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2012-01-31 02:40:32 +00:00
|
|
|
static unsigned long __read_mostly max_load_balance_interval = HZ/10;
|
|
|
|
|
2013-10-07 10:29:33 +00:00
|
|
|
enum fbq_type { regular, remote, all };
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
/*
|
2019-11-12 14:50:43 +00:00
|
|
|
* 'group_type' describes the group of CPUs at the moment of load balancing.
|
|
|
|
*
|
2019-10-18 13:26:31 +00:00
|
|
|
* The enum is ordered by pulling priority, with the group with lowest priority
|
2019-11-12 14:50:43 +00:00
|
|
|
* first so the group_type can simply be compared when selecting the busiest
|
|
|
|
* group. See update_sd_pick_busiest().
|
2019-10-18 13:26:31 +00:00
|
|
|
*/
|
2018-07-04 10:17:40 +00:00
|
|
|
enum group_type {
|
2019-11-12 14:50:43 +00:00
|
|
|
/* The group has spare capacity that can be used to run more tasks. */
|
2019-10-18 13:26:31 +00:00
|
|
|
group_has_spare = 0,
|
2019-11-12 14:50:43 +00:00
|
|
|
/*
|
|
|
|
* The group is fully used and the tasks don't compete for more CPU
|
|
|
|
* cycles. Nevertheless, some tasks might wait before running.
|
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
group_fully_busy,
|
2019-11-12 14:50:43 +00:00
|
|
|
/*
|
|
|
|
* SD_ASYM_CPUCAPACITY only: One task doesn't fit with CPU's capacity
|
|
|
|
* and must be migrated to a more powerful CPU.
|
|
|
|
*/
|
2018-07-04 10:17:40 +00:00
|
|
|
group_misfit_task,
|
2019-11-12 14:50:43 +00:00
|
|
|
/*
|
|
|
|
* SD_ASYM_PACKING only: One local CPU with higher capacity is available,
|
|
|
|
* and the task should be migrated to it instead of running on the
|
|
|
|
* current CPU.
|
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
group_asym_packing,
|
2019-11-12 14:50:43 +00:00
|
|
|
/*
|
|
|
|
* The tasks' affinity constraints previously prevented the scheduler
|
|
|
|
* from balancing the load across the system.
|
|
|
|
*/
|
2018-07-04 10:17:40 +00:00
|
|
|
group_imbalanced,
|
2019-11-12 14:50:43 +00:00
|
|
|
/*
|
|
|
|
* The CPU is overloaded and can't provide expected CPU cycles to all
|
|
|
|
* tasks.
|
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
group_overloaded
|
|
|
|
};
|
|
|
|
|
|
|
|
enum migration_type {
|
|
|
|
migrate_load = 0,
|
|
|
|
migrate_util,
|
|
|
|
migrate_task,
|
|
|
|
migrate_misfit
|
2018-07-04 10:17:40 +00:00
|
|
|
};
|
|
|
|
|
2012-02-22 18:27:40 +00:00
|
|
|
#define LBF_ALL_PINNED 0x01
|
2012-02-20 20:49:09 +00:00
|
|
|
#define LBF_NEED_BREAK 0x02
|
2013-08-19 10:41:09 +00:00
|
|
|
#define LBF_DST_PINNED 0x04
|
|
|
|
#define LBF_SOME_PINNED 0x08
|
2017-12-21 10:20:23 +00:00
|
|
|
#define LBF_NOHZ_STATS 0x10
|
2018-02-13 10:31:17 +00:00
|
|
|
#define LBF_NOHZ_AGAIN 0x20
|
2012-02-22 18:27:40 +00:00
|
|
|
|
|
|
|
struct lb_env {
|
|
|
|
struct sched_domain *sd;
|
|
|
|
|
|
|
|
struct rq *src_rq;
|
2012-06-19 12:17:34 +00:00
|
|
|
int src_cpu;
|
2012-02-22 18:27:40 +00:00
|
|
|
|
|
|
|
int dst_cpu;
|
|
|
|
struct rq *dst_rq;
|
|
|
|
|
2012-06-19 12:13:15 +00:00
|
|
|
struct cpumask *dst_grpmask;
|
|
|
|
int new_dst_cpu;
|
2012-02-22 18:27:40 +00:00
|
|
|
enum cpu_idle_type idle;
|
2012-05-02 12:20:37 +00:00
|
|
|
long imbalance;
|
2012-07-12 08:10:13 +00:00
|
|
|
/* The set of CPUs under consideration for load-balancing */
|
|
|
|
struct cpumask *cpus;
|
|
|
|
|
2012-02-22 18:27:40 +00:00
|
|
|
unsigned int flags;
|
2012-02-20 20:49:09 +00:00
|
|
|
|
|
|
|
unsigned int loop;
|
|
|
|
unsigned int loop_break;
|
|
|
|
unsigned int loop_max;
|
2013-10-07 10:29:33 +00:00
|
|
|
|
|
|
|
enum fbq_type fbq_type;
|
2019-10-18 13:26:31 +00:00
|
|
|
enum migration_type migration_type;
|
2014-08-20 09:48:29 +00:00
|
|
|
struct list_head tasks;
|
2012-02-22 18:27:40 +00:00
|
|
|
};
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
/*
|
|
|
|
* Is this task likely cache-hot:
|
|
|
|
*/
|
2014-06-10 08:58:43 +00:00
|
|
|
static int task_hot(struct task_struct *p, struct lb_env *env)
|
2011-10-25 08:00:11 +00:00
|
|
|
{
|
|
|
|
s64 delta;
|
|
|
|
|
2014-08-20 09:48:01 +00:00
|
|
|
lockdep_assert_held(&env->src_rq->lock);
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
if (p->sched_class != &fair_sched_class)
|
|
|
|
return 0;
|
|
|
|
|
2018-11-05 11:21:55 +00:00
|
|
|
if (unlikely(task_has_idle_policy(p)))
|
2011-10-25 08:00:11 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Buddy candidates are cache hot:
|
|
|
|
*/
|
2014-06-10 08:58:43 +00:00
|
|
|
if (sched_feat(CACHE_HOT_BUDDY) && env->dst_rq->nr_running &&
|
2011-10-25 08:00:11 +00:00
|
|
|
(&p->se == cfs_rq_of(&p->se)->next ||
|
|
|
|
&p->se == cfs_rq_of(&p->se)->last))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
if (sysctl_sched_migration_cost == -1)
|
|
|
|
return 1;
|
|
|
|
if (sysctl_sched_migration_cost == 0)
|
|
|
|
return 0;
|
|
|
|
|
2014-06-10 08:58:43 +00:00
|
|
|
delta = rq_clock_task(env->src_rq) - p->se.exec_start;
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
return delta < (s64)sysctl_sched_migration_cost;
|
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:00 +00:00
|
|
|
#ifdef CONFIG_NUMA_BALANCING
|
2015-05-15 02:59:36 +00:00
|
|
|
/*
|
2015-06-16 11:55:59 +00:00
|
|
|
* Returns 1, if task migration degrades locality
|
|
|
|
* Returns 0, if task migration improves locality i.e migration preferred.
|
|
|
|
* Returns -1, if task migration is not affected by locality.
|
2015-05-15 02:59:36 +00:00
|
|
|
*/
|
2015-06-16 11:55:59 +00:00
|
|
|
static int migrate_degrades_locality(struct task_struct *p, struct lb_env *env)
|
2013-10-07 10:29:00 +00:00
|
|
|
{
|
2014-05-15 17:03:06 +00:00
|
|
|
struct numa_group *numa_group = rcu_dereference(p->numa_group);
|
2018-06-20 17:02:56 +00:00
|
|
|
unsigned long src_weight, dst_weight;
|
|
|
|
int src_nid, dst_nid, dist;
|
2013-10-07 10:29:00 +00:00
|
|
|
|
2015-08-11 16:24:21 +00:00
|
|
|
if (!static_branch_likely(&sched_numa_balancing))
|
2015-06-16 11:55:59 +00:00
|
|
|
return -1;
|
|
|
|
|
2015-08-11 11:00:12 +00:00
|
|
|
if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
|
2015-06-16 11:55:59 +00:00
|
|
|
return -1;
|
2013-10-07 10:29:01 +00:00
|
|
|
|
|
|
|
src_nid = cpu_to_node(env->src_cpu);
|
|
|
|
dst_nid = cpu_to_node(env->dst_cpu);
|
|
|
|
|
2013-10-07 10:29:27 +00:00
|
|
|
if (src_nid == dst_nid)
|
2015-06-16 11:55:59 +00:00
|
|
|
return -1;
|
2013-10-07 10:29:01 +00:00
|
|
|
|
2015-06-16 11:55:59 +00:00
|
|
|
/* Migrating away from the preferred node is always bad. */
|
|
|
|
if (src_nid == p->numa_preferred_nid) {
|
|
|
|
if (env->src_rq->nr_running > env->src_rq->nr_preferred_running)
|
|
|
|
return 1;
|
|
|
|
else
|
|
|
|
return -1;
|
|
|
|
}
|
2014-05-15 17:03:06 +00:00
|
|
|
|
2015-05-15 02:59:36 +00:00
|
|
|
/* Encourage migration to the preferred node. */
|
|
|
|
if (dst_nid == p->numa_preferred_nid)
|
2015-06-16 11:55:59 +00:00
|
|
|
return 0;
|
2014-05-15 17:03:06 +00:00
|
|
|
|
2017-06-23 16:55:27 +00:00
|
|
|
/* Leaving a core idle is often worse than degrading locality. */
|
2018-06-20 17:02:56 +00:00
|
|
|
if (env->idle == CPU_IDLE)
|
2017-06-23 16:55:27 +00:00
|
|
|
return -1;
|
|
|
|
|
2018-06-20 17:02:56 +00:00
|
|
|
dist = node_distance(src_nid, dst_nid);
|
2015-05-15 02:59:36 +00:00
|
|
|
if (numa_group) {
|
2018-06-20 17:02:56 +00:00
|
|
|
src_weight = group_weight(p, src_nid, dist);
|
|
|
|
dst_weight = group_weight(p, dst_nid, dist);
|
2015-05-15 02:59:36 +00:00
|
|
|
} else {
|
2018-06-20 17:02:56 +00:00
|
|
|
src_weight = task_weight(p, src_nid, dist);
|
|
|
|
dst_weight = task_weight(p, dst_nid, dist);
|
2014-05-15 17:03:06 +00:00
|
|
|
}
|
|
|
|
|
2018-06-20 17:02:56 +00:00
|
|
|
return dst_weight < src_weight;
|
2013-10-07 10:29:01 +00:00
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:00 +00:00
|
|
|
#else
|
2015-06-16 11:55:59 +00:00
|
|
|
static inline int migrate_degrades_locality(struct task_struct *p,
|
2013-10-07 10:29:00 +00:00
|
|
|
struct lb_env *env)
|
|
|
|
{
|
2015-06-16 11:55:59 +00:00
|
|
|
return -1;
|
2013-10-07 10:29:01 +00:00
|
|
|
}
|
2013-10-07 10:29:00 +00:00
|
|
|
#endif
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/*
|
|
|
|
* can_migrate_task - may task p from runqueue rq be migrated to this_cpu?
|
|
|
|
*/
|
|
|
|
static
|
2012-02-22 11:47:19 +00:00
|
|
|
int can_migrate_task(struct task_struct *p, struct lb_env *env)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2015-06-16 11:55:59 +00:00
|
|
|
int tsk_cache_hot;
|
2014-08-20 09:48:01 +00:00
|
|
|
|
|
|
|
lockdep_assert_held(&env->src_rq->lock);
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/*
|
|
|
|
* We do not migrate tasks that are:
|
2013-04-23 08:27:40 +00:00
|
|
|
* 1) throttled_lb_pair, or
|
2019-04-23 14:26:36 +00:00
|
|
|
* 2) cannot be migrated to this CPU due to cpus_ptr, or
|
2013-04-23 08:27:40 +00:00
|
|
|
* 3) running (obviously), or
|
|
|
|
* 4) are cache-hot on their current CPU.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2013-04-23 08:27:40 +00:00
|
|
|
if (throttled_lb_pair(task_group(p), env->src_cpu, env->dst_cpu))
|
|
|
|
return 0;
|
|
|
|
|
2019-04-23 14:26:36 +00:00
|
|
|
if (!cpumask_test_cpu(env->dst_cpu, p->cpus_ptr)) {
|
2013-04-23 08:27:42 +00:00
|
|
|
int cpu;
|
2012-06-19 12:13:15 +00:00
|
|
|
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(p->se.statistics.nr_failed_migrations_affine);
|
2012-06-19 12:13:15 +00:00
|
|
|
|
2013-08-19 10:41:09 +00:00
|
|
|
env->flags |= LBF_SOME_PINNED;
|
|
|
|
|
2012-06-19 12:13:15 +00:00
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Remember if this task can be migrated to any other CPU in
|
2012-06-19 12:13:15 +00:00
|
|
|
* our sched_group. We may want to revisit it if we couldn't
|
|
|
|
* meet load balance goals by pulling other tasks on src_cpu.
|
|
|
|
*
|
2017-06-07 19:18:57 +00:00
|
|
|
* Avoid computing new_dst_cpu for NEWLY_IDLE or if we have
|
|
|
|
* already computed one in current iteration.
|
2012-06-19 12:13:15 +00:00
|
|
|
*/
|
2017-06-07 19:18:57 +00:00
|
|
|
if (env->idle == CPU_NEWLY_IDLE || (env->flags & LBF_DST_PINNED))
|
2012-06-19 12:13:15 +00:00
|
|
|
return 0;
|
|
|
|
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/* Prevent to re-select dst_cpu via env's CPUs: */
|
2013-04-23 08:27:42 +00:00
|
|
|
for_each_cpu_and(cpu, env->dst_grpmask, env->cpus) {
|
2019-04-23 14:26:36 +00:00
|
|
|
if (cpumask_test_cpu(cpu, p->cpus_ptr)) {
|
2013-08-19 10:41:09 +00:00
|
|
|
env->flags |= LBF_DST_PINNED;
|
2013-04-23 08:27:42 +00:00
|
|
|
env->new_dst_cpu = cpu;
|
|
|
|
break;
|
|
|
|
}
|
2012-06-19 12:13:15 +00:00
|
|
|
}
|
2013-04-23 08:27:42 +00:00
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2012-06-19 12:13:15 +00:00
|
|
|
|
|
|
|
/* Record that we found atleast one task that could run on dst_cpu */
|
2012-02-22 11:47:19 +00:00
|
|
|
env->flags &= ~LBF_ALL_PINNED;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2012-02-22 18:27:40 +00:00
|
|
|
if (task_running(env->src_rq, p)) {
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(p->se.statistics.nr_failed_migrations_running);
|
2009-12-17 16:00:43 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Aggressive migration if:
|
2013-10-07 10:29:00 +00:00
|
|
|
* 1) destination numa is preferred
|
|
|
|
* 2) task is cache cold, or
|
|
|
|
* 3) too many balance attempts have failed.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2015-06-16 11:55:59 +00:00
|
|
|
tsk_cache_hot = migrate_degrades_locality(p, env);
|
|
|
|
if (tsk_cache_hot == -1)
|
|
|
|
tsk_cache_hot = task_hot(p, env);
|
2013-10-07 10:29:00 +00:00
|
|
|
|
2015-06-16 11:55:59 +00:00
|
|
|
if (tsk_cache_hot <= 0 ||
|
2014-09-22 18:36:12 +00:00
|
|
|
env->sd->nr_balance_failed > env->sd->cache_nice_tries) {
|
2015-06-16 11:55:59 +00:00
|
|
|
if (tsk_cache_hot == 1) {
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(env->sd->lb_hot_gained[env->idle]);
|
|
|
|
schedstat_inc(p->se.statistics.nr_forced_migrations);
|
2013-10-07 10:29:00 +00:00
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(p->se.statistics.nr_failed_migrations_hot);
|
2013-04-10 06:04:55 +00:00
|
|
|
return 0;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2009-12-17 16:45:42 +00:00
|
|
|
/*
|
2014-08-20 09:48:29 +00:00
|
|
|
* detach_task() -- detach the task for the migration specified in env
|
|
|
|
*/
|
|
|
|
static void detach_task(struct task_struct *p, struct lb_env *env)
|
|
|
|
{
|
|
|
|
lockdep_assert_held(&env->src_rq->lock);
|
|
|
|
|
2017-02-21 16:15:21 +00:00
|
|
|
deactivate_task(env->src_rq, p, DEQUEUE_NOCLOCK);
|
2014-08-20 09:48:29 +00:00
|
|
|
set_task_cpu(p, env->dst_cpu);
|
|
|
|
}
|
|
|
|
|
2009-12-17 16:45:42 +00:00
|
|
|
/*
|
2014-08-20 09:48:01 +00:00
|
|
|
* detach_one_task() -- tries to dequeue exactly one task from env->src_rq, as
|
2009-12-17 16:45:42 +00:00
|
|
|
* part of active balancing operations within "domain".
|
|
|
|
*
|
2014-08-20 09:48:01 +00:00
|
|
|
* Returns a task if successful and NULL otherwise.
|
2009-12-17 16:45:42 +00:00
|
|
|
*/
|
2014-08-20 09:48:01 +00:00
|
|
|
static struct task_struct *detach_one_task(struct lb_env *env)
|
2009-12-17 16:45:42 +00:00
|
|
|
{
|
2017-09-13 10:24:30 +00:00
|
|
|
struct task_struct *p;
|
2009-12-17 16:45:42 +00:00
|
|
|
|
2014-08-20 09:48:01 +00:00
|
|
|
lockdep_assert_held(&env->src_rq->lock);
|
|
|
|
|
2017-09-13 10:24:30 +00:00
|
|
|
list_for_each_entry_reverse(p,
|
|
|
|
&env->src_rq->cfs_tasks, se.group_node) {
|
2012-02-20 20:49:09 +00:00
|
|
|
if (!can_migrate_task(p, env))
|
|
|
|
continue;
|
2009-12-17 16:45:42 +00:00
|
|
|
|
2014-08-20 09:48:29 +00:00
|
|
|
detach_task(p, env);
|
2014-08-20 09:48:01 +00:00
|
|
|
|
2012-02-20 20:49:09 +00:00
|
|
|
/*
|
2014-08-20 09:48:01 +00:00
|
|
|
* Right now, this is only the second place where
|
2014-08-20 09:48:29 +00:00
|
|
|
* lb_gained[env->idle] is updated (other is detach_tasks)
|
2014-08-20 09:48:01 +00:00
|
|
|
* so we can safely collect stats here rather than
|
2014-08-20 09:48:29 +00:00
|
|
|
* inside detach_tasks().
|
2012-02-20 20:49:09 +00:00
|
|
|
*/
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(env->sd->lb_gained[env->idle]);
|
2014-08-20 09:48:01 +00:00
|
|
|
return p;
|
2009-12-17 16:45:42 +00:00
|
|
|
}
|
2014-08-20 09:48:01 +00:00
|
|
|
return NULL;
|
2009-12-17 16:45:42 +00:00
|
|
|
}
|
|
|
|
|
2012-04-17 11:38:40 +00:00
|
|
|
static const unsigned int sched_nr_migrate_break = 32;
|
|
|
|
|
2012-03-09 23:07:36 +00:00
|
|
|
/*
|
2019-10-18 13:26:31 +00:00
|
|
|
* detach_tasks() -- tries to detach up to imbalance load/util/tasks from
|
2014-08-20 09:48:29 +00:00
|
|
|
* busiest_rq, as part of a balancing operation within domain "sd".
|
2012-03-09 23:07:36 +00:00
|
|
|
*
|
2014-08-20 09:48:29 +00:00
|
|
|
* Returns number of detached tasks if successful and 0 otherwise.
|
2012-03-09 23:07:36 +00:00
|
|
|
*/
|
2014-08-20 09:48:29 +00:00
|
|
|
static int detach_tasks(struct lb_env *env)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2012-03-09 23:07:36 +00:00
|
|
|
struct list_head *tasks = &env->src_rq->cfs_tasks;
|
2019-10-18 13:26:31 +00:00
|
|
|
unsigned long util, load;
|
2012-03-09 23:07:36 +00:00
|
|
|
struct task_struct *p;
|
2014-08-20 09:48:29 +00:00
|
|
|
int detached = 0;
|
|
|
|
|
|
|
|
lockdep_assert_held(&env->src_rq->lock);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2012-05-02 12:20:37 +00:00
|
|
|
if (env->imbalance <= 0)
|
2012-03-09 23:07:36 +00:00
|
|
|
return 0;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2012-03-09 23:07:36 +00:00
|
|
|
while (!list_empty(tasks)) {
|
2015-07-05 22:11:51 +00:00
|
|
|
/*
|
|
|
|
* We don't want to steal all, otherwise we may be treated likewise,
|
|
|
|
* which could at worst lead to a livelock crash.
|
|
|
|
*/
|
|
|
|
if (env->idle != CPU_NOT_IDLE && env->src_rq->nr_running <= 1)
|
|
|
|
break;
|
|
|
|
|
2017-09-13 10:24:30 +00:00
|
|
|
p = list_last_entry(tasks, struct task_struct, se.group_node);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2012-02-20 20:49:09 +00:00
|
|
|
env->loop++;
|
|
|
|
/* We've more or less seen every task there is, call it quits */
|
2012-03-09 23:07:36 +00:00
|
|
|
if (env->loop > env->loop_max)
|
2012-02-20 20:49:09 +00:00
|
|
|
break;
|
2012-03-09 23:07:36 +00:00
|
|
|
|
|
|
|
/* take a breather every nr_migrate tasks */
|
2012-02-20 20:49:09 +00:00
|
|
|
if (env->loop > env->loop_break) {
|
2012-04-17 11:38:40 +00:00
|
|
|
env->loop_break += sched_nr_migrate_break;
|
2012-02-22 11:47:19 +00:00
|
|
|
env->flags |= LBF_NEED_BREAK;
|
2009-12-17 16:25:20 +00:00
|
|
|
break;
|
2011-09-22 13:30:18 +00:00
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2013-04-23 08:27:40 +00:00
|
|
|
if (!can_migrate_task(p, env))
|
2012-02-20 20:49:09 +00:00
|
|
|
goto next;
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
switch (env->migration_type) {
|
|
|
|
case migrate_load:
|
|
|
|
load = task_h_load(p);
|
2012-03-09 23:07:36 +00:00
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
if (sched_feat(LB_MIN) &&
|
|
|
|
load < 16 && !env->sd->nr_balance_failed)
|
|
|
|
goto next;
|
2012-02-20 20:49:09 +00:00
|
|
|
|
2019-11-29 14:04:47 +00:00
|
|
|
/*
|
|
|
|
* Make sure that we don't migrate too much load.
|
|
|
|
* Nevertheless, let relax the constraint if
|
|
|
|
* scheduler fails to find a good waiting task to
|
|
|
|
* migrate.
|
|
|
|
*/
|
|
|
|
if (load/2 > env->imbalance &&
|
|
|
|
env->sd->nr_balance_failed <= env->sd->cache_nice_tries)
|
2019-10-18 13:26:31 +00:00
|
|
|
goto next;
|
|
|
|
|
|
|
|
env->imbalance -= load;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case migrate_util:
|
|
|
|
util = task_util_est(p);
|
|
|
|
|
|
|
|
if (util > env->imbalance)
|
|
|
|
goto next;
|
|
|
|
|
|
|
|
env->imbalance -= util;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case migrate_task:
|
|
|
|
env->imbalance--;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case migrate_misfit:
|
2019-10-18 13:26:35 +00:00
|
|
|
/* This is not a misfit task */
|
|
|
|
if (task_fits_capacity(p, capacity_of(env->src_cpu)))
|
2019-10-18 13:26:31 +00:00
|
|
|
goto next;
|
|
|
|
|
|
|
|
env->imbalance = 0;
|
|
|
|
break;
|
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2014-08-20 09:48:29 +00:00
|
|
|
detach_task(p, env);
|
|
|
|
list_add(&p->se.group_node, &env->tasks);
|
|
|
|
|
|
|
|
detached++;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2019-07-26 21:19:37 +00:00
|
|
|
#ifdef CONFIG_PREEMPTION
|
2009-12-17 16:25:20 +00:00
|
|
|
/*
|
|
|
|
* NEWIDLE balancing is a source of latency, so preemptible
|
2014-08-20 09:48:29 +00:00
|
|
|
* kernels will stop after the first task is detached to minimize
|
2009-12-17 16:25:20 +00:00
|
|
|
* the critical section.
|
|
|
|
*/
|
2012-03-09 23:07:36 +00:00
|
|
|
if (env->idle == CPU_NEWLY_IDLE)
|
2009-12-17 16:25:20 +00:00
|
|
|
break;
|
2009-12-17 16:00:43 +00:00
|
|
|
#endif
|
|
|
|
|
2009-12-17 16:25:20 +00:00
|
|
|
/*
|
|
|
|
* We only want to steal up to the prescribed amount of
|
2019-10-18 13:26:31 +00:00
|
|
|
* load/util/tasks.
|
2009-12-17 16:25:20 +00:00
|
|
|
*/
|
2012-05-02 12:20:37 +00:00
|
|
|
if (env->imbalance <= 0)
|
2009-12-17 16:25:20 +00:00
|
|
|
break;
|
2012-02-20 20:49:09 +00:00
|
|
|
|
|
|
|
continue;
|
|
|
|
next:
|
2017-09-13 10:24:30 +00:00
|
|
|
list_move(&p->se.group_node, tasks);
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
2012-03-09 23:07:36 +00:00
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/*
|
2014-08-20 09:48:29 +00:00
|
|
|
* Right now, this is one of only two places we collect this stat
|
|
|
|
* so we can safely collect detach_one_task() stats here rather
|
|
|
|
* than inside detach_one_task().
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_add(env->sd->lb_gained[env->idle], detached);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2014-08-20 09:48:29 +00:00
|
|
|
return detached;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* attach_task() -- attach the task detached by detach_task() to its new rq.
|
|
|
|
*/
|
|
|
|
static void attach_task(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
lockdep_assert_held(&rq->lock);
|
|
|
|
|
|
|
|
BUG_ON(task_rq(p) != rq);
|
2017-02-21 16:15:21 +00:00
|
|
|
activate_task(rq, p, ENQUEUE_NOCLOCK);
|
2014-08-20 09:48:29 +00:00
|
|
|
check_preempt_curr(rq, p, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* attach_one_task() -- attaches the task returned from detach_one_task() to
|
|
|
|
* its new rq.
|
|
|
|
*/
|
|
|
|
static void attach_one_task(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
2016-10-04 14:04:35 +00:00
|
|
|
struct rq_flags rf;
|
|
|
|
|
|
|
|
rq_lock(rq, &rf);
|
2017-02-21 16:15:21 +00:00
|
|
|
update_rq_clock(rq);
|
2014-08-20 09:48:29 +00:00
|
|
|
attach_task(rq, p);
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_unlock(rq, &rf);
|
2014-08-20 09:48:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* attach_tasks() -- attaches all tasks detached by detach_tasks() to their
|
|
|
|
* new rq.
|
|
|
|
*/
|
|
|
|
static void attach_tasks(struct lb_env *env)
|
|
|
|
{
|
|
|
|
struct list_head *tasks = &env->tasks;
|
|
|
|
struct task_struct *p;
|
2016-10-04 14:04:35 +00:00
|
|
|
struct rq_flags rf;
|
2014-08-20 09:48:29 +00:00
|
|
|
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_lock(env->dst_rq, &rf);
|
2017-02-21 16:15:21 +00:00
|
|
|
update_rq_clock(env->dst_rq);
|
2014-08-20 09:48:29 +00:00
|
|
|
|
|
|
|
while (!list_empty(tasks)) {
|
|
|
|
p = list_first_entry(tasks, struct task_struct, se.group_node);
|
|
|
|
list_del_init(&p->se.group_node);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2014-08-20 09:48:29 +00:00
|
|
|
attach_task(env->dst_rq, p);
|
|
|
|
}
|
|
|
|
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_unlock(env->dst_rq, &rf);
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2019-06-03 11:54:24 +00:00
|
|
|
#ifdef CONFIG_NO_HZ_COMMON
|
2018-02-13 10:31:18 +00:00
|
|
|
static inline bool cfs_rq_has_blocked(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
if (cfs_rq->avg.load_avg)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (cfs_rq->avg.util_avg)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-06-28 15:45:09 +00:00
|
|
|
static inline bool others_have_blocked(struct rq *rq)
|
2018-06-28 15:45:05 +00:00
|
|
|
{
|
|
|
|
if (READ_ONCE(rq->avg_rt.util_avg))
|
|
|
|
return true;
|
|
|
|
|
2018-06-28 15:45:07 +00:00
|
|
|
if (READ_ONCE(rq->avg_dl.util_avg))
|
|
|
|
return true;
|
|
|
|
|
2018-09-25 09:17:42 +00:00
|
|
|
#ifdef CONFIG_HAVE_SCHED_AVG_IRQ
|
2018-06-28 15:45:09 +00:00
|
|
|
if (READ_ONCE(rq->avg_irq.util_avg))
|
|
|
|
return true;
|
|
|
|
#endif
|
|
|
|
|
2018-06-28 15:45:05 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-06-03 11:54:24 +00:00
|
|
|
static inline void update_blocked_load_status(struct rq *rq, bool has_blocked)
|
|
|
|
{
|
|
|
|
rq->last_blocked_load_update_tick = jiffies;
|
|
|
|
|
|
|
|
if (!has_blocked)
|
|
|
|
rq->has_blocked_load = 0;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline bool cfs_rq_has_blocked(struct cfs_rq *cfs_rq) { return false; }
|
|
|
|
static inline bool others_have_blocked(struct rq *rq) { return false; }
|
|
|
|
static inline void update_blocked_load_status(struct rq *rq, bool has_blocked) {}
|
|
|
|
#endif
|
|
|
|
|
2019-11-18 13:21:19 +00:00
|
|
|
static bool __update_blocked_others(struct rq *rq, bool *done)
|
|
|
|
{
|
|
|
|
const struct sched_class *curr_class;
|
|
|
|
u64 now = rq_clock_pelt(rq);
|
|
|
|
bool decayed;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* update_load_avg() can call cpufreq_update_util(). Make sure that RT,
|
|
|
|
* DL and IRQ signals have been updated before updating CFS.
|
|
|
|
*/
|
|
|
|
curr_class = rq->curr->sched_class;
|
|
|
|
|
|
|
|
decayed = update_rt_rq_load_avg(now, rq, curr_class == &rt_sched_class) |
|
|
|
|
update_dl_rq_load_avg(now, rq, curr_class == &dl_sched_class) |
|
|
|
|
update_irq_load_avg(rq, 0);
|
|
|
|
|
|
|
|
if (others_have_blocked(rq))
|
|
|
|
*done = false;
|
|
|
|
|
|
|
|
return decayed;
|
|
|
|
}
|
|
|
|
|
2018-02-13 10:31:18 +00:00
|
|
|
#ifdef CONFIG_FAIR_GROUP_SCHED
|
|
|
|
|
2019-02-06 16:14:22 +00:00
|
|
|
static inline bool cfs_rq_is_decayed(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
if (cfs_rq->load.weight)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (cfs_rq->avg.load_sum)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (cfs_rq->avg.util_sum)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (cfs_rq->avg.runnable_load_sum)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-11-18 13:21:19 +00:00
|
|
|
static bool __update_blocked_fair(struct rq *rq, bool *done)
|
2010-11-15 23:47:02 +00:00
|
|
|
{
|
2019-02-06 16:14:22 +00:00
|
|
|
struct cfs_rq *cfs_rq, *pos;
|
2019-11-18 13:21:19 +00:00
|
|
|
bool decayed = false;
|
|
|
|
int cpu = cpu_of(rq);
|
2019-10-30 11:18:29 +00:00
|
|
|
|
2011-07-13 11:09:25 +00:00
|
|
|
/*
|
|
|
|
* Iterates the task_group tree in a bottom up fashion, see
|
|
|
|
* list_add_leaf_cfs_rq() for details.
|
|
|
|
*/
|
2019-02-06 16:14:22 +00:00
|
|
|
for_each_leaf_cfs_rq_safe(rq, cfs_rq, pos) {
|
2017-03-17 13:47:22 +00:00
|
|
|
struct sched_entity *se;
|
|
|
|
|
2019-11-18 13:21:19 +00:00
|
|
|
if (update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq)) {
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
update_tg_load_avg(cfs_rq, 0);
|
2016-11-08 09:53:46 +00:00
|
|
|
|
2019-11-18 13:21:19 +00:00
|
|
|
if (cfs_rq == &rq->cfs)
|
|
|
|
decayed = true;
|
|
|
|
}
|
|
|
|
|
2017-03-17 13:47:22 +00:00
|
|
|
/* Propagate pending load changes to the parent, if any: */
|
|
|
|
se = cfs_rq->tg->se[cpu];
|
|
|
|
if (se && !skip_blocked_update(se))
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq_of(se), se, 0);
|
2017-04-26 00:43:50 +00:00
|
|
|
|
2019-02-06 16:14:22 +00:00
|
|
|
/*
|
|
|
|
* There can be a lot of idle CPU cgroups. Don't let fully
|
|
|
|
* decayed cfs_rqs linger on the list.
|
|
|
|
*/
|
|
|
|
if (cfs_rq_is_decayed(cfs_rq))
|
|
|
|
list_del_leaf_cfs_rq(cfs_rq);
|
|
|
|
|
2018-02-13 10:31:18 +00:00
|
|
|
/* Don't need periodic decay once load/util_avg are null */
|
|
|
|
if (cfs_rq_has_blocked(cfs_rq))
|
2019-11-18 13:21:19 +00:00
|
|
|
*done = false;
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
}
|
2018-08-31 15:22:55 +00:00
|
|
|
|
2019-11-18 13:21:19 +00:00
|
|
|
return decayed;
|
2010-11-15 23:47:02 +00:00
|
|
|
}
|
|
|
|
|
2011-07-13 11:09:25 +00:00
|
|
|
/*
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
* Compute the hierarchical load factor for cfs_rq and all its ascendants.
|
2011-07-13 11:09:25 +00:00
|
|
|
* This needs to be done in a top-down fashion because the load of a child
|
|
|
|
* group is a fraction of its parents load.
|
|
|
|
*/
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
static void update_cfs_rq_h_load(struct cfs_rq *cfs_rq)
|
2011-07-13 11:09:25 +00:00
|
|
|
{
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
struct rq *rq = rq_of(cfs_rq);
|
|
|
|
struct sched_entity *se = cfs_rq->tg->se[cpu_of(rq)];
|
2012-08-08 19:46:40 +00:00
|
|
|
unsigned long now = jiffies;
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
unsigned long load;
|
2012-08-08 19:46:40 +00:00
|
|
|
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
if (cfs_rq->last_h_load_update == now)
|
2012-08-08 19:46:40 +00:00
|
|
|
return;
|
|
|
|
|
2019-03-19 12:36:10 +00:00
|
|
|
WRITE_ONCE(cfs_rq->h_load_next, NULL);
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
for_each_sched_entity(se) {
|
|
|
|
cfs_rq = cfs_rq_of(se);
|
2019-03-19 12:36:10 +00:00
|
|
|
WRITE_ONCE(cfs_rq->h_load_next, se);
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
if (cfs_rq->last_h_load_update == now)
|
|
|
|
break;
|
|
|
|
}
|
2012-08-08 19:46:40 +00:00
|
|
|
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
if (!se) {
|
2015-07-15 00:04:42 +00:00
|
|
|
cfs_rq->h_load = cfs_rq_load_avg(cfs_rq);
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
cfs_rq->last_h_load_update = now;
|
|
|
|
}
|
|
|
|
|
2019-03-19 12:36:10 +00:00
|
|
|
while ((se = READ_ONCE(cfs_rq->h_load_next)) != NULL) {
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
load = cfs_rq->h_load;
|
2015-07-15 00:04:42 +00:00
|
|
|
load = div64_ul(load * se->avg.load_avg,
|
|
|
|
cfs_rq_load_avg(cfs_rq) + 1);
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
cfs_rq = group_cfs_rq(se);
|
|
|
|
cfs_rq->h_load = load;
|
|
|
|
cfs_rq->last_h_load_update = now;
|
|
|
|
}
|
2011-07-13 11:09:25 +00:00
|
|
|
}
|
|
|
|
|
2012-02-20 20:49:09 +00:00
|
|
|
static unsigned long task_h_load(struct task_struct *p)
|
2009-12-17 16:47:12 +00:00
|
|
|
{
|
2012-02-20 20:49:09 +00:00
|
|
|
struct cfs_rq *cfs_rq = task_cfs_rq(p);
|
2009-12-17 16:47:12 +00:00
|
|
|
|
sched: Move h_load calculation to task_h_load()
The bad thing about update_h_load(), which computes hierarchical load
factor for task groups, is that it is called for each task group in the
system before every load balancer run, and since rebalance can be
triggered very often, this function can eat really a lot of cpu time if
there are many cpu cgroups in the system.
Although the situation was improved significantly by commit a35b646
('sched, cgroup: Reduce rq->lock hold times for large cgroup
hierarchies'), the problem still can arise under some kinds of loads,
e.g. when cpus are switching from idle to busy and back very frequently.
For instance, when I start 1000 of processes that wake up every
millisecond on my 8 cpus host, 'top' and 'perf top' show:
Cpu(s): 17.8%us, 24.3%sy, 0.0%ni, 57.9%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 243K cycles
7.57% [kernel] [k] __schedule
7.08% [kernel] [k] timerqueue_add
6.13% libc-2.12.so [.] usleep
Then if I create 10000 *idle* cpu cgroups (no processes in them), cpu
usage increases significantly although the 'wakers' are still executing
in the root cpu cgroup:
Cpu(s): 19.1%us, 48.7%sy, 0.0%ni, 31.6%id, 0.0%wa, 0.0%hi, 0.7%si
Events: 230K cycles
24.56% [kernel] [k] tg_load_down
5.76% [kernel] [k] __schedule
This happens because this particular kind of load triggers 'new idle'
rebalance very frequently, which requires calling update_h_load(),
which, in turn, calls tg_load_down() for every *idle* cpu cgroup even
though it is absolutely useless, because idle cpu cgroups have no tasks
to pull.
This patch tries to improve the situation by making h_load calculation
proceed only when h_load is really necessary. To achieve this, it
substitutes update_h_load() with update_cfs_rq_h_load(), which computes
h_load only for a given cfs_rq and all its ascendants, and makes the
load balancer call this function whenever it considers if a task should
be pulled, i.e. it moves h_load calculations directly to task_h_load().
For h_load of the same cfs_rq not to be updated multiple times (in case
several tasks in the same cgroup are considered during the same balance
run), the patch keeps the time of the last h_load update for each cfs_rq
and breaks calculation when it finds h_load to be uptodate.
The benefit of it is that h_load is computed only for those cfs_rq's,
which really need it, in particular all idle task groups are skipped.
Although this, in fact, moves h_load calculation under rq lock, it
should not affect latency much, because the amount of work done under rq
lock while trying to pull tasks is limited by sched_nr_migrate.
After the patch applied with the setup described above (1000 wakers in
the root cgroup and 10000 idle cgroups), I get:
Cpu(s): 16.9%us, 24.8%sy, 0.0%ni, 58.4%id, 0.0%wa, 0.0%hi, 0.0%si
Events: 242K cycles
7.57% [kernel] [k] __schedule
6.70% [kernel] [k] timerqueue_add
5.93% libc-2.12.so [.] usleep
Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1373896159-1278-1-git-send-email-vdavydov@parallels.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-07-15 13:49:19 +00:00
|
|
|
update_cfs_rq_h_load(cfs_rq);
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
return div64_ul(p->se.avg.load_avg * cfs_rq->h_load,
|
2015-07-15 00:04:42 +00:00
|
|
|
cfs_rq_load_avg(cfs_rq) + 1);
|
2009-12-17 16:47:12 +00:00
|
|
|
}
|
|
|
|
#else
|
2019-11-18 13:21:19 +00:00
|
|
|
static bool __update_blocked_fair(struct rq *rq, bool *done)
|
2010-11-15 23:47:02 +00:00
|
|
|
{
|
2015-07-15 00:04:38 +00:00
|
|
|
struct cfs_rq *cfs_rq = &rq->cfs;
|
2019-11-18 13:21:19 +00:00
|
|
|
bool decayed;
|
2019-10-30 11:18:29 +00:00
|
|
|
|
2019-11-18 13:21:19 +00:00
|
|
|
decayed = update_cfs_rq_load_avg(cfs_rq_clock_pelt(cfs_rq), cfs_rq);
|
|
|
|
if (cfs_rq_has_blocked(cfs_rq))
|
|
|
|
*done = false;
|
2019-10-30 11:18:29 +00:00
|
|
|
|
2019-11-18 13:21:19 +00:00
|
|
|
return decayed;
|
2010-11-15 23:47:02 +00:00
|
|
|
}
|
|
|
|
|
2012-02-20 20:49:09 +00:00
|
|
|
static unsigned long task_h_load(struct task_struct *p)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
return p->se.avg.load_avg;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
2009-12-17 16:47:12 +00:00
|
|
|
#endif
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2019-11-18 13:21:19 +00:00
|
|
|
static void update_blocked_averages(int cpu)
|
|
|
|
{
|
|
|
|
bool decayed = false, done = true;
|
|
|
|
struct rq *rq = cpu_rq(cpu);
|
|
|
|
struct rq_flags rf;
|
|
|
|
|
|
|
|
rq_lock_irqsave(rq, &rf);
|
|
|
|
update_rq_clock(rq);
|
|
|
|
|
|
|
|
decayed |= __update_blocked_others(rq, &done);
|
|
|
|
decayed |= __update_blocked_fair(rq, &done);
|
|
|
|
|
|
|
|
update_blocked_load_status(rq, !done);
|
|
|
|
if (decayed)
|
|
|
|
cpufreq_update_util(rq, 0);
|
|
|
|
rq_unlock_irqrestore(rq, &rf);
|
|
|
|
}
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/********** Helpers for find_busiest_group ************************/
|
2014-07-28 18:16:28 +00:00
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/*
|
|
|
|
* sg_lb_stats - stats of a sched_group required for load_balancing
|
|
|
|
*/
|
|
|
|
struct sg_lb_stats {
|
|
|
|
unsigned long avg_load; /*Avg load across the CPUs of the group */
|
|
|
|
unsigned long group_load; /* Total load over the CPUs of the group */
|
2014-05-26 22:19:37 +00:00
|
|
|
unsigned long group_capacity;
|
2015-08-14 16:23:12 +00:00
|
|
|
unsigned long group_util; /* Total utilization of the group */
|
2019-10-18 13:26:32 +00:00
|
|
|
unsigned int sum_nr_running; /* Nr of tasks running in the group */
|
2019-10-18 13:26:29 +00:00
|
|
|
unsigned int sum_h_nr_running; /* Nr of CFS tasks running in the group */
|
2013-08-19 13:22:57 +00:00
|
|
|
unsigned int idle_cpus;
|
|
|
|
unsigned int group_weight;
|
2014-07-28 18:16:28 +00:00
|
|
|
enum group_type group_type;
|
2019-10-18 13:26:28 +00:00
|
|
|
unsigned int group_asym_packing; /* Tasks should be moved to preferred CPU */
|
2018-07-04 10:17:40 +00:00
|
|
|
unsigned long group_misfit_task_load; /* A CPU has a task too big for its capacity */
|
2013-10-07 10:29:33 +00:00
|
|
|
#ifdef CONFIG_NUMA_BALANCING
|
|
|
|
unsigned int nr_numa_running;
|
|
|
|
unsigned int nr_preferred_running;
|
|
|
|
#endif
|
2009-12-17 16:00:43 +00:00
|
|
|
};
|
|
|
|
|
2013-08-06 08:36:43 +00:00
|
|
|
/*
|
|
|
|
* sd_lb_stats - Structure to store the statistics of a sched_domain
|
|
|
|
* during load balancing.
|
|
|
|
*/
|
|
|
|
struct sd_lb_stats {
|
|
|
|
struct sched_group *busiest; /* Busiest group in this sd */
|
|
|
|
struct sched_group *local; /* Local group in this sd */
|
|
|
|
unsigned long total_load; /* Total load of all groups in sd */
|
2014-05-26 22:19:37 +00:00
|
|
|
unsigned long total_capacity; /* Total capacity of all groups in sd */
|
2013-08-06 08:36:43 +00:00
|
|
|
unsigned long avg_load; /* Average load across all groups in sd */
|
2019-10-18 13:26:31 +00:00
|
|
|
unsigned int prefer_sibling; /* tasks should go to sibling first */
|
2013-08-06 08:36:43 +00:00
|
|
|
|
|
|
|
struct sg_lb_stats busiest_stat;/* Statistics of the busiest group */
|
2013-08-19 13:22:57 +00:00
|
|
|
struct sg_lb_stats local_stat; /* Statistics of the local group */
|
2013-08-06 08:36:43 +00:00
|
|
|
};
|
|
|
|
|
2013-08-19 13:22:57 +00:00
|
|
|
static inline void init_sd_lb_stats(struct sd_lb_stats *sds)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Skimp on the clearing to avoid duplicate work. We can avoid clearing
|
|
|
|
* local_stat because update_sg_lb_stats() does a full clear/assignment.
|
2019-10-18 13:26:31 +00:00
|
|
|
* We must however set busiest_stat::group_type and
|
|
|
|
* busiest_stat::idle_cpus to the worst busiest group because
|
|
|
|
* update_sd_pick_busiest() reads these before assignment.
|
2013-08-19 13:22:57 +00:00
|
|
|
*/
|
|
|
|
*sds = (struct sd_lb_stats){
|
|
|
|
.busiest = NULL,
|
|
|
|
.local = NULL,
|
|
|
|
.total_load = 0UL,
|
2014-05-26 22:19:37 +00:00
|
|
|
.total_capacity = 0UL,
|
2013-08-19 13:22:57 +00:00
|
|
|
.busiest_stat = {
|
2019-10-18 13:26:31 +00:00
|
|
|
.idle_cpus = UINT_MAX,
|
|
|
|
.group_type = group_has_spare,
|
2013-08-19 13:22:57 +00:00
|
|
|
},
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2018-09-04 09:36:26 +00:00
|
|
|
static unsigned long scale_rt_capacity(struct sched_domain *sd, int cpu)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
|
|
|
struct rq *rq = cpu_rq(cpu);
|
2019-06-17 15:00:17 +00:00
|
|
|
unsigned long max = arch_scale_cpu_capacity(cpu);
|
2018-06-28 15:45:12 +00:00
|
|
|
unsigned long used, free;
|
|
|
|
unsigned long irq;
|
2012-05-22 12:04:28 +00:00
|
|
|
|
2018-07-19 12:00:06 +00:00
|
|
|
irq = cpu_util_irq(rq);
|
2014-02-27 09:40:35 +00:00
|
|
|
|
2018-06-28 15:45:12 +00:00
|
|
|
if (unlikely(irq >= max))
|
|
|
|
return 1;
|
2010-10-05 00:03:22 +00:00
|
|
|
|
2018-06-28 15:45:12 +00:00
|
|
|
used = READ_ONCE(rq->avg_rt.util_avg);
|
|
|
|
used += READ_ONCE(rq->avg_dl.util_avg);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2018-06-28 15:45:12 +00:00
|
|
|
if (unlikely(used >= max))
|
|
|
|
return 1;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2018-06-28 15:45:12 +00:00
|
|
|
free = max - used;
|
2018-07-19 12:00:06 +00:00
|
|
|
|
|
|
|
return scale_irq_capacity(free, irq, max);
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2014-05-26 22:19:38 +00:00
|
|
|
static void update_cpu_capacity(struct sched_domain *sd, int cpu)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2018-09-04 09:36:26 +00:00
|
|
|
unsigned long capacity = scale_rt_capacity(sd, cpu);
|
2009-12-17 16:00:43 +00:00
|
|
|
struct sched_group *sdg = sd->groups;
|
|
|
|
|
2019-06-17 15:00:17 +00:00
|
|
|
cpu_rq(cpu)->cpu_capacity_orig = arch_scale_cpu_capacity(cpu);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2014-05-26 22:19:38 +00:00
|
|
|
if (!capacity)
|
|
|
|
capacity = 1;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2014-05-26 22:19:38 +00:00
|
|
|
cpu_rq(cpu)->cpu_capacity = capacity;
|
|
|
|
sdg->sgc->capacity = capacity;
|
2016-10-14 13:41:09 +00:00
|
|
|
sdg->sgc->min_capacity = capacity;
|
2018-07-04 10:17:41 +00:00
|
|
|
sdg->sgc->max_capacity = capacity;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2014-05-26 22:19:37 +00:00
|
|
|
void update_group_capacity(struct sched_domain *sd, int cpu)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
|
|
|
struct sched_domain *child = sd->child;
|
|
|
|
struct sched_group *group, *sdg = sd->groups;
|
2018-07-04 10:17:41 +00:00
|
|
|
unsigned long capacity, min_capacity, max_capacity;
|
2011-12-12 19:21:08 +00:00
|
|
|
unsigned long interval;
|
|
|
|
|
|
|
|
interval = msecs_to_jiffies(sd->balance_interval);
|
|
|
|
interval = clamp(interval, 1UL, max_load_balance_interval);
|
2014-05-26 22:19:37 +00:00
|
|
|
sdg->sgc->next_update = jiffies + interval;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
|
|
|
if (!child) {
|
2014-05-26 22:19:38 +00:00
|
|
|
update_cpu_capacity(sd, cpu);
|
2009-12-17 16:00:43 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-03-03 10:35:03 +00:00
|
|
|
capacity = 0;
|
2016-10-14 13:41:09 +00:00
|
|
|
min_capacity = ULONG_MAX;
|
2018-07-04 10:17:41 +00:00
|
|
|
max_capacity = 0;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2012-05-23 16:00:43 +00:00
|
|
|
if (child->flags & SD_OVERLAP) {
|
|
|
|
/*
|
|
|
|
* SD_OVERLAP domains cannot assume that child groups
|
|
|
|
* span the current group.
|
|
|
|
*/
|
|
|
|
|
2017-05-01 09:03:12 +00:00
|
|
|
for_each_cpu(cpu, sched_group_span(sdg)) {
|
2020-01-04 13:08:28 +00:00
|
|
|
unsigned long cpu_cap = capacity_of(cpu);
|
2013-08-28 09:44:39 +00:00
|
|
|
|
2020-01-04 13:08:28 +00:00
|
|
|
capacity += cpu_cap;
|
|
|
|
min_capacity = min(cpu_cap, min_capacity);
|
|
|
|
max_capacity = max(cpu_cap, max_capacity);
|
2013-08-28 09:44:39 +00:00
|
|
|
}
|
2012-05-23 16:00:43 +00:00
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* !SD_OVERLAP domains can assume that child groups
|
|
|
|
* span the current group.
|
2015-07-05 09:33:48 +00:00
|
|
|
*/
|
2012-05-23 16:00:43 +00:00
|
|
|
|
|
|
|
group = child->groups;
|
|
|
|
do {
|
2016-10-14 13:41:09 +00:00
|
|
|
struct sched_group_capacity *sgc = group->sgc;
|
|
|
|
|
|
|
|
capacity += sgc->capacity;
|
|
|
|
min_capacity = min(sgc->min_capacity, min_capacity);
|
2018-07-04 10:17:41 +00:00
|
|
|
max_capacity = max(sgc->max_capacity, max_capacity);
|
2012-05-23 16:00:43 +00:00
|
|
|
group = group->next;
|
|
|
|
} while (group != child->groups);
|
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2014-05-26 22:19:37 +00:00
|
|
|
sdg->sgc->capacity = capacity;
|
2016-10-14 13:41:09 +00:00
|
|
|
sdg->sgc->min_capacity = min_capacity;
|
2018-07-04 10:17:41 +00:00
|
|
|
sdg->sgc->max_capacity = max_capacity;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2010-06-08 04:57:02 +00:00
|
|
|
/*
|
2015-02-27 15:54:11 +00:00
|
|
|
* Check whether the capacity of the rq has been noticeably reduced by side
|
|
|
|
* activity. The imbalance_pct is used for the threshold.
|
|
|
|
* Return true is the capacity is reduced
|
2010-06-08 04:57:02 +00:00
|
|
|
*/
|
|
|
|
static inline int
|
2015-02-27 15:54:11 +00:00
|
|
|
check_cpu_capacity(struct rq *rq, struct sched_domain *sd)
|
2010-06-08 04:57:02 +00:00
|
|
|
{
|
2015-02-27 15:54:11 +00:00
|
|
|
return ((rq->cpu_capacity * sd->imbalance_pct) <
|
|
|
|
(rq->cpu_capacity_orig * 100));
|
2010-06-08 04:57:02 +00:00
|
|
|
}
|
|
|
|
|
2019-02-11 17:59:45 +00:00
|
|
|
/*
|
|
|
|
* Check whether a rq has a misfit task and if it looks like we can actually
|
|
|
|
* help that task: we can migrate the task to a CPU of higher capacity, or
|
|
|
|
* the task's current CPU is heavily pressured.
|
|
|
|
*/
|
|
|
|
static inline int check_misfit_status(struct rq *rq, struct sched_domain *sd)
|
|
|
|
{
|
|
|
|
return rq->misfit_task_load &&
|
|
|
|
(rq->cpu_capacity_orig < rq->rd->max_cpu_capacity ||
|
|
|
|
check_cpu_capacity(rq, sd));
|
|
|
|
}
|
|
|
|
|
2013-08-15 18:29:29 +00:00
|
|
|
/*
|
|
|
|
* Group imbalance indicates (and tries to solve) the problem where balancing
|
2019-04-23 14:26:36 +00:00
|
|
|
* groups is inadequate due to ->cpus_ptr constraints.
|
2013-08-15 18:29:29 +00:00
|
|
|
*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Imagine a situation of two groups of 4 CPUs each and 4 tasks each with a
|
|
|
|
* cpumask covering 1 CPU of the first group and 3 CPUs of the second group.
|
2013-08-15 18:29:29 +00:00
|
|
|
* Something like:
|
|
|
|
*
|
2016-11-23 06:37:00 +00:00
|
|
|
* { 0 1 2 3 } { 4 5 6 7 }
|
|
|
|
* * * * *
|
2013-08-15 18:29:29 +00:00
|
|
|
*
|
|
|
|
* If we were to balance group-wise we'd place two tasks in the first group and
|
|
|
|
* two tasks in the second group. Clearly this is undesired as it will overload
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* cpu 3 and leave one of the CPUs in the second group unused.
|
2013-08-15 18:29:29 +00:00
|
|
|
*
|
|
|
|
* The current solution to this issue is detecting the skew in the first group
|
2013-08-19 10:41:09 +00:00
|
|
|
* by noticing the lower domain failed to reach balance and had difficulty
|
|
|
|
* moving tasks due to affinity constraints.
|
2013-08-15 18:29:29 +00:00
|
|
|
*
|
|
|
|
* When this is so detected; this group becomes a candidate for busiest; see
|
2013-10-13 17:36:15 +00:00
|
|
|
* update_sd_pick_busiest(). And calculate_imbalance() and
|
2013-08-19 10:41:09 +00:00
|
|
|
* find_busiest_group() avoid some of the usual balance conditions to allow it
|
2013-08-15 18:29:29 +00:00
|
|
|
* to create an effective group imbalance.
|
|
|
|
*
|
|
|
|
* This is a somewhat tricky proposition since the next run might not find the
|
|
|
|
* group imbalance and decide the groups need to be balanced again. A most
|
|
|
|
* subtle and fragile situation.
|
|
|
|
*/
|
|
|
|
|
2013-08-19 10:41:09 +00:00
|
|
|
static inline int sg_imbalanced(struct sched_group *group)
|
2013-08-15 18:29:29 +00:00
|
|
|
{
|
2014-05-26 22:19:37 +00:00
|
|
|
return group->sgc->imbalance;
|
2013-08-15 18:29:29 +00:00
|
|
|
}
|
|
|
|
|
2013-08-28 09:50:34 +00:00
|
|
|
/*
|
2015-02-27 15:54:11 +00:00
|
|
|
* group_has_capacity returns true if the group has spare capacity that could
|
|
|
|
* be used by some tasks.
|
|
|
|
* We consider that a group has spare capacity if the * number of task is
|
2015-08-14 16:23:12 +00:00
|
|
|
* smaller than the number of CPUs or if the utilization is lower than the
|
|
|
|
* available capacity for CFS tasks.
|
2015-02-27 15:54:11 +00:00
|
|
|
* For the latter, we use a threshold to stabilize the state, to take into
|
|
|
|
* account the variance of the tasks' load and to return true if the available
|
|
|
|
* capacity in meaningful for the load balancer.
|
|
|
|
* As an example, an available capacity of 1% can appear but it doesn't make
|
|
|
|
* any benefit for the load balance.
|
2013-08-28 09:50:34 +00:00
|
|
|
*/
|
2015-02-27 15:54:11 +00:00
|
|
|
static inline bool
|
2019-10-18 13:26:38 +00:00
|
|
|
group_has_capacity(unsigned int imbalance_pct, struct sg_lb_stats *sgs)
|
2013-08-28 09:50:34 +00:00
|
|
|
{
|
2019-10-18 13:26:32 +00:00
|
|
|
if (sgs->sum_nr_running < sgs->group_weight)
|
2015-02-27 15:54:11 +00:00
|
|
|
return true;
|
2013-08-28 10:40:38 +00:00
|
|
|
|
2015-02-27 15:54:11 +00:00
|
|
|
if ((sgs->group_capacity * 100) >
|
2019-10-18 13:26:38 +00:00
|
|
|
(sgs->group_util * imbalance_pct))
|
2015-02-27 15:54:11 +00:00
|
|
|
return true;
|
2013-08-28 09:50:34 +00:00
|
|
|
|
2015-02-27 15:54:11 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* group_is_overloaded returns true if the group has more tasks than it can
|
|
|
|
* handle.
|
|
|
|
* group_is_overloaded is not equals to !group_has_capacity because a group
|
|
|
|
* with the exact right number of tasks, has no more spare capacity but is not
|
|
|
|
* overloaded so both group_has_capacity and group_is_overloaded return
|
|
|
|
* false.
|
|
|
|
*/
|
|
|
|
static inline bool
|
2019-10-18 13:26:38 +00:00
|
|
|
group_is_overloaded(unsigned int imbalance_pct, struct sg_lb_stats *sgs)
|
2015-02-27 15:54:11 +00:00
|
|
|
{
|
2019-10-18 13:26:32 +00:00
|
|
|
if (sgs->sum_nr_running <= sgs->group_weight)
|
2015-02-27 15:54:11 +00:00
|
|
|
return false;
|
2013-08-28 09:50:34 +00:00
|
|
|
|
2015-02-27 15:54:11 +00:00
|
|
|
if ((sgs->group_capacity * 100) <
|
2019-10-18 13:26:38 +00:00
|
|
|
(sgs->group_util * imbalance_pct))
|
2015-02-27 15:54:11 +00:00
|
|
|
return true;
|
2013-08-28 09:50:34 +00:00
|
|
|
|
2015-02-27 15:54:11 +00:00
|
|
|
return false;
|
2013-08-28 09:50:34 +00:00
|
|
|
}
|
|
|
|
|
2016-10-14 13:41:10 +00:00
|
|
|
/*
|
2018-07-04 10:17:41 +00:00
|
|
|
* group_smaller_min_cpu_capacity: Returns true if sched_group sg has smaller
|
2016-10-14 13:41:10 +00:00
|
|
|
* per-CPU capacity than sched_group ref.
|
|
|
|
*/
|
|
|
|
static inline bool
|
2018-07-04 10:17:41 +00:00
|
|
|
group_smaller_min_cpu_capacity(struct sched_group *sg, struct sched_group *ref)
|
2016-10-14 13:41:10 +00:00
|
|
|
{
|
2019-06-04 07:01:52 +00:00
|
|
|
return fits_capacity(sg->sgc->min_capacity, ref->sgc->min_capacity);
|
2016-10-14 13:41:10 +00:00
|
|
|
}
|
|
|
|
|
2018-07-04 10:17:41 +00:00
|
|
|
/*
|
|
|
|
* group_smaller_max_cpu_capacity: Returns true if sched_group sg has smaller
|
|
|
|
* per-CPU capacity_orig than sched_group ref.
|
|
|
|
*/
|
|
|
|
static inline bool
|
|
|
|
group_smaller_max_cpu_capacity(struct sched_group *sg, struct sched_group *ref)
|
|
|
|
{
|
2019-06-04 07:01:52 +00:00
|
|
|
return fits_capacity(sg->sgc->max_capacity, ref->sgc->max_capacity);
|
2018-07-04 10:17:41 +00:00
|
|
|
}
|
|
|
|
|
2015-09-15 10:56:45 +00:00
|
|
|
static inline enum
|
2019-10-18 13:26:38 +00:00
|
|
|
group_type group_classify(unsigned int imbalance_pct,
|
2019-10-18 13:26:31 +00:00
|
|
|
struct sched_group *group,
|
2015-09-15 10:56:45 +00:00
|
|
|
struct sg_lb_stats *sgs)
|
2014-07-28 18:16:28 +00:00
|
|
|
{
|
2019-10-18 13:26:38 +00:00
|
|
|
if (group_is_overloaded(imbalance_pct, sgs))
|
2014-07-28 18:16:28 +00:00
|
|
|
return group_overloaded;
|
|
|
|
|
|
|
|
if (sg_imbalanced(group))
|
|
|
|
return group_imbalanced;
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
if (sgs->group_asym_packing)
|
|
|
|
return group_asym_packing;
|
|
|
|
|
2018-07-04 10:17:40 +00:00
|
|
|
if (sgs->group_misfit_task_load)
|
|
|
|
return group_misfit_task;
|
|
|
|
|
2019-10-18 13:26:38 +00:00
|
|
|
if (!group_has_capacity(imbalance_pct, sgs))
|
2019-10-18 13:26:31 +00:00
|
|
|
return group_fully_busy;
|
|
|
|
|
|
|
|
return group_has_spare;
|
2014-07-28 18:16:28 +00:00
|
|
|
}
|
|
|
|
|
2018-02-13 15:54:17 +00:00
|
|
|
static bool update_nohz_stats(struct rq *rq, bool force)
|
2017-12-21 10:20:23 +00:00
|
|
|
{
|
|
|
|
#ifdef CONFIG_NO_HZ_COMMON
|
|
|
|
unsigned int cpu = rq->cpu;
|
|
|
|
|
2018-02-13 10:31:17 +00:00
|
|
|
if (!rq->has_blocked_load)
|
|
|
|
return false;
|
|
|
|
|
2017-12-21 10:20:23 +00:00
|
|
|
if (!cpumask_test_cpu(cpu, nohz.idle_cpus_mask))
|
2018-02-13 10:31:17 +00:00
|
|
|
return false;
|
2017-12-21 10:20:23 +00:00
|
|
|
|
2018-02-13 15:54:17 +00:00
|
|
|
if (!force && !time_after(jiffies, rq->last_blocked_load_update_tick))
|
2018-02-13 10:31:17 +00:00
|
|
|
return true;
|
2017-12-21 10:20:23 +00:00
|
|
|
|
|
|
|
update_blocked_averages(cpu);
|
2018-02-13 10:31:17 +00:00
|
|
|
|
|
|
|
return rq->has_blocked_load;
|
|
|
|
#else
|
|
|
|
return false;
|
2017-12-21 10:20:23 +00:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/**
|
|
|
|
* update_sg_lb_stats - Update sched_group's statistics for load balancing.
|
2012-06-08 20:18:33 +00:00
|
|
|
* @env: The load balancing environment.
|
2009-12-17 16:00:43 +00:00
|
|
|
* @group: sched_group whose statistics are to be updated.
|
|
|
|
* @sgs: variable to hold the statistics for this group.
|
2018-12-03 09:56:24 +00:00
|
|
|
* @sg_status: Holds flag indicating the status of the sched_group
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2012-05-02 12:20:37 +00:00
|
|
|
static inline void update_sg_lb_stats(struct lb_env *env,
|
2018-12-03 09:56:24 +00:00
|
|
|
struct sched_group *group,
|
|
|
|
struct sg_lb_stats *sgs,
|
|
|
|
int *sg_status)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2019-10-18 13:26:31 +00:00
|
|
|
int i, nr_running, local_group;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2013-08-28 08:32:32 +00:00
|
|
|
memset(sgs, 0, sizeof(*sgs));
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
local_group = cpumask_test_cpu(env->dst_cpu, sched_group_span(group));
|
|
|
|
|
2017-05-01 09:03:12 +00:00
|
|
|
for_each_cpu_and(i, sched_group_span(group), env->cpus) {
|
2009-12-17 16:00:43 +00:00
|
|
|
struct rq *rq = cpu_rq(i);
|
|
|
|
|
2018-02-13 15:54:17 +00:00
|
|
|
if ((env->flags & LBF_NOHZ_STATS) && update_nohz_stats(rq, false))
|
2018-02-13 10:31:17 +00:00
|
|
|
env->flags |= LBF_NOHZ_AGAIN;
|
2017-12-21 10:20:23 +00:00
|
|
|
|
2019-10-18 13:26:33 +00:00
|
|
|
sgs->group_load += cpu_load(rq);
|
2015-08-14 16:23:12 +00:00
|
|
|
sgs->group_util += cpu_util(i);
|
2019-10-18 13:26:29 +00:00
|
|
|
sgs->sum_h_nr_running += rq->cfs.h_nr_running;
|
2014-06-23 19:16:49 +00:00
|
|
|
|
2015-11-25 19:09:38 +00:00
|
|
|
nr_running = rq->nr_running;
|
2019-10-18 13:26:32 +00:00
|
|
|
sgs->sum_nr_running += nr_running;
|
|
|
|
|
2015-11-25 19:09:38 +00:00
|
|
|
if (nr_running > 1)
|
2018-12-03 09:56:24 +00:00
|
|
|
*sg_status |= SG_OVERLOAD;
|
2014-06-23 19:16:49 +00:00
|
|
|
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
if (cpu_overutilized(i))
|
|
|
|
*sg_status |= SG_OVERUTILIZED;
|
2014-06-23 19:16:49 +00:00
|
|
|
|
2013-10-07 10:29:33 +00:00
|
|
|
#ifdef CONFIG_NUMA_BALANCING
|
|
|
|
sgs->nr_numa_running += rq->nr_numa_running;
|
|
|
|
sgs->nr_preferred_running += rq->nr_preferred_running;
|
|
|
|
#endif
|
2015-11-25 19:09:38 +00:00
|
|
|
/*
|
|
|
|
* No need to call idle_cpu() if nr_running is not 0
|
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
if (!nr_running && idle_cpu(i)) {
|
2010-09-17 22:02:32 +00:00
|
|
|
sgs->idle_cpus++;
|
2019-10-18 13:26:31 +00:00
|
|
|
/* Idle cpu can't have misfit task */
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (local_group)
|
|
|
|
continue;
|
2018-07-04 10:17:40 +00:00
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
/* Check for a misfit task on the cpu */
|
2018-07-04 10:17:40 +00:00
|
|
|
if (env->sd->flags & SD_ASYM_CPUCAPACITY &&
|
sched/fair: Set rq->rd->overload when misfit
Idle balance is a great opportunity to pull a misfit task. However,
there are scenarios where misfit tasks are present but idle balance is
prevented by the overload flag.
A good example of this is a workload of n identical tasks. Let's suppose
we have a 2+2 Arm big.LITTLE system. We then spawn 4 fairly
CPU-intensive tasks - for the sake of simplicity let's say they are just
CPU hogs, even when running on big CPUs.
They are identical tasks, so on an SMP system they should all end at
(roughly) the same time. However, in our case the LITTLE CPUs are less
performing than the big CPUs, so tasks running on the LITTLEs will have
a longer completion time.
This means that the big CPUs will complete their work earlier, at which
point they should pull the tasks from the LITTLEs. What we want to
happen is summarized as follows:
a,b,c,d are our CPU-hogging tasks _ signifies idling
LITTLE_0 | a a a a _ _
LITTLE_1 | b b b b _ _
---------|-------------
big_0 | c c c c a a
big_1 | d d d d b b
^
^
Tasks end on the big CPUs, idle balance happens
and the misfit tasks are pulled straight away
This however won't happen, because currently the overload flag is only
set when there is any CPU that has more than one runnable task - which
may very well not be the case here if our CPU-hogging workload is all
there is to run.
As such, this commit sets the overload flag in update_sg_lb_stats when
a group is flagged as having a misfit task.
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: gaku.inami.xh@renesas.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1530699470-29808-10-git-send-email-morten.rasmussen@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-04 10:17:47 +00:00
|
|
|
sgs->group_misfit_task_load < rq->misfit_task_load) {
|
2018-07-04 10:17:40 +00:00
|
|
|
sgs->group_misfit_task_load = rq->misfit_task_load;
|
2018-12-03 09:56:24 +00:00
|
|
|
*sg_status |= SG_OVERLOAD;
|
sched/fair: Set rq->rd->overload when misfit
Idle balance is a great opportunity to pull a misfit task. However,
there are scenarios where misfit tasks are present but idle balance is
prevented by the overload flag.
A good example of this is a workload of n identical tasks. Let's suppose
we have a 2+2 Arm big.LITTLE system. We then spawn 4 fairly
CPU-intensive tasks - for the sake of simplicity let's say they are just
CPU hogs, even when running on big CPUs.
They are identical tasks, so on an SMP system they should all end at
(roughly) the same time. However, in our case the LITTLE CPUs are less
performing than the big CPUs, so tasks running on the LITTLEs will have
a longer completion time.
This means that the big CPUs will complete their work earlier, at which
point they should pull the tasks from the LITTLEs. What we want to
happen is summarized as follows:
a,b,c,d are our CPU-hogging tasks _ signifies idling
LITTLE_0 | a a a a _ _
LITTLE_1 | b b b b _ _
---------|-------------
big_0 | c c c c a a
big_1 | d d d d b b
^
^
Tasks end on the big CPUs, idle balance happens
and the misfit tasks are pulled straight away
This however won't happen, because currently the overload flag is only
set when there is any CPU that has more than one runnable task - which
may very well not be the case here if our CPU-hogging workload is all
there is to run.
As such, this commit sets the overload flag in update_sg_lb_stats when
a group is flagged as having a misfit task.
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dietmar.eggemann@arm.com
Cc: gaku.inami.xh@renesas.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1530699470-29808-10-git-send-email-morten.rasmussen@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-04 10:17:47 +00:00
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
/* Check if dst CPU is idle and preferred to this group */
|
|
|
|
if (env->sd->flags & SD_ASYM_PACKING &&
|
|
|
|
env->idle != CPU_NOT_IDLE &&
|
|
|
|
sgs->sum_h_nr_running &&
|
|
|
|
sched_asym_prefer(env->dst_cpu, group->asym_prefer_cpu)) {
|
|
|
|
sgs->group_asym_packing = 1;
|
|
|
|
}
|
|
|
|
|
2014-05-26 22:19:37 +00:00
|
|
|
sgs->group_capacity = group->sgc->capacity;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2010-09-17 22:02:32 +00:00
|
|
|
sgs->group_weight = group->group_weight;
|
2013-08-28 09:50:34 +00:00
|
|
|
|
2019-10-18 13:26:38 +00:00
|
|
|
sgs->group_type = group_classify(env->sd->imbalance_pct, group, sgs);
|
2019-10-18 13:26:31 +00:00
|
|
|
|
|
|
|
/* Computing avg_load makes sense only when group is overloaded */
|
|
|
|
if (sgs->group_type == group_overloaded)
|
|
|
|
sgs->avg_load = (sgs->group_load * SCHED_CAPACITY_SCALE) /
|
|
|
|
sgs->group_capacity;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2010-06-08 04:57:02 +00:00
|
|
|
/**
|
|
|
|
* update_sd_pick_busiest - return 1 on busiest group
|
2012-06-08 20:18:33 +00:00
|
|
|
* @env: The load balancing environment.
|
2010-06-08 04:57:02 +00:00
|
|
|
* @sds: sched_domain statistics
|
|
|
|
* @sg: sched_group candidate to be checked for being the busiest
|
2010-06-10 02:06:21 +00:00
|
|
|
* @sgs: sched_group statistics
|
2010-06-08 04:57:02 +00:00
|
|
|
*
|
|
|
|
* Determine if @sg is a busier group than the previously selected
|
|
|
|
* busiest group.
|
2013-07-12 18:45:47 +00:00
|
|
|
*
|
|
|
|
* Return: %true if @sg is a busier group than the previously selected
|
|
|
|
* busiest group. %false otherwise.
|
2010-06-08 04:57:02 +00:00
|
|
|
*/
|
2012-05-02 12:20:37 +00:00
|
|
|
static bool update_sd_pick_busiest(struct lb_env *env,
|
2010-06-08 04:57:02 +00:00
|
|
|
struct sd_lb_stats *sds,
|
|
|
|
struct sched_group *sg,
|
2012-05-02 12:20:37 +00:00
|
|
|
struct sg_lb_stats *sgs)
|
2010-06-08 04:57:02 +00:00
|
|
|
{
|
2014-07-28 18:16:28 +00:00
|
|
|
struct sg_lb_stats *busiest = &sds->busiest_stat;
|
2010-06-08 04:57:02 +00:00
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
/* Make sure that there is at least one task to pull */
|
|
|
|
if (!sgs->sum_h_nr_running)
|
|
|
|
return false;
|
|
|
|
|
2018-07-04 10:17:42 +00:00
|
|
|
/*
|
|
|
|
* Don't try to pull misfit tasks we can't help.
|
|
|
|
* We can use max_capacity here as reduction in capacity on some
|
|
|
|
* CPUs in the group should either be possible to resolve
|
|
|
|
* internally or be covered by avg_load imbalance (eventually).
|
|
|
|
*/
|
|
|
|
if (sgs->group_type == group_misfit_task &&
|
|
|
|
(!group_smaller_max_cpu_capacity(sg, sds->local) ||
|
2019-10-18 13:26:31 +00:00
|
|
|
sds->local_stat.group_type != group_has_spare))
|
2018-07-04 10:17:42 +00:00
|
|
|
return false;
|
|
|
|
|
2014-07-28 18:16:28 +00:00
|
|
|
if (sgs->group_type > busiest->group_type)
|
2010-06-08 04:57:02 +00:00
|
|
|
return true;
|
|
|
|
|
2014-07-28 18:16:28 +00:00
|
|
|
if (sgs->group_type < busiest->group_type)
|
|
|
|
return false;
|
|
|
|
|
2016-10-14 13:41:10 +00:00
|
|
|
/*
|
2019-10-18 13:26:31 +00:00
|
|
|
* The candidate and the current busiest group are the same type of
|
|
|
|
* group. Let check which one is the busiest according to the type.
|
2016-10-14 13:41:10 +00:00
|
|
|
*/
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
switch (sgs->group_type) {
|
|
|
|
case group_overloaded:
|
|
|
|
/* Select the overloaded group with highest avg_load. */
|
|
|
|
if (sgs->avg_load <= busiest->avg_load)
|
|
|
|
return false;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case group_imbalanced:
|
|
|
|
/*
|
|
|
|
* Select the 1st imbalanced group as we don't have any way to
|
|
|
|
* choose one more than another.
|
|
|
|
*/
|
2016-10-14 13:41:10 +00:00
|
|
|
return false;
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
case group_asym_packing:
|
|
|
|
/* Prefer to move from lowest priority CPU's work */
|
|
|
|
if (sched_asym_prefer(sg->asym_prefer_cpu, sds->busiest->asym_prefer_cpu))
|
|
|
|
return false;
|
|
|
|
break;
|
2010-06-08 04:57:02 +00:00
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
case group_misfit_task:
|
|
|
|
/*
|
|
|
|
* If we have more than one misfit sg go with the biggest
|
|
|
|
* misfit.
|
|
|
|
*/
|
|
|
|
if (sgs->group_misfit_task_load < busiest->group_misfit_task_load)
|
|
|
|
return false;
|
|
|
|
break;
|
2010-06-08 04:57:02 +00:00
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
case group_fully_busy:
|
|
|
|
/*
|
|
|
|
* Select the fully busy group with highest avg_load. In
|
|
|
|
* theory, there is no need to pull task from such kind of
|
|
|
|
* group because tasks have all compute capacity that they need
|
|
|
|
* but we can still improve the overall throughput by reducing
|
|
|
|
* contention when accessing shared HW resources.
|
|
|
|
*
|
|
|
|
* XXX for now avg_load is not computed and always 0 so we
|
|
|
|
* select the 1st one.
|
|
|
|
*/
|
|
|
|
if (sgs->avg_load <= busiest->avg_load)
|
|
|
|
return false;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case group_has_spare:
|
|
|
|
/*
|
2019-12-20 11:04:53 +00:00
|
|
|
* Select not overloaded group with lowest number of idle cpus
|
|
|
|
* and highest number of running tasks. We could also compare
|
|
|
|
* the spare capacity which is more stable but it can end up
|
|
|
|
* that the group has less spare capacity but finally more idle
|
2019-10-18 13:26:31 +00:00
|
|
|
* CPUs which means less opportunity to pull tasks.
|
|
|
|
*/
|
2019-12-20 11:04:53 +00:00
|
|
|
if (sgs->idle_cpus > busiest->idle_cpus)
|
2019-10-18 13:26:31 +00:00
|
|
|
return false;
|
2019-12-20 11:04:53 +00:00
|
|
|
else if ((sgs->idle_cpus == busiest->idle_cpus) &&
|
|
|
|
(sgs->sum_nr_running <= busiest->sum_nr_running))
|
|
|
|
return false;
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
break;
|
2010-06-08 04:57:02 +00:00
|
|
|
}
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
/*
|
|
|
|
* Candidate sg has no more than one task per CPU and has higher
|
|
|
|
* per-CPU capacity. Migrating tasks to less capable CPUs may harm
|
|
|
|
* throughput. Maximize throughput, power/energy consequences are not
|
|
|
|
* considered.
|
|
|
|
*/
|
|
|
|
if ((env->sd->flags & SD_ASYM_CPUCAPACITY) &&
|
|
|
|
(sgs->group_type <= group_fully_busy) &&
|
|
|
|
(group_smaller_min_cpu_capacity(sds->local, sg)))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
2010-06-08 04:57:02 +00:00
|
|
|
}
|
|
|
|
|
2013-10-07 10:29:33 +00:00
|
|
|
#ifdef CONFIG_NUMA_BALANCING
|
|
|
|
static inline enum fbq_type fbq_classify_group(struct sg_lb_stats *sgs)
|
|
|
|
{
|
2019-10-18 13:26:29 +00:00
|
|
|
if (sgs->sum_h_nr_running > sgs->nr_numa_running)
|
2013-10-07 10:29:33 +00:00
|
|
|
return regular;
|
2019-10-18 13:26:29 +00:00
|
|
|
if (sgs->sum_h_nr_running > sgs->nr_preferred_running)
|
2013-10-07 10:29:33 +00:00
|
|
|
return remote;
|
|
|
|
return all;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline enum fbq_type fbq_classify_rq(struct rq *rq)
|
|
|
|
{
|
|
|
|
if (rq->nr_running > rq->nr_numa_running)
|
|
|
|
return regular;
|
|
|
|
if (rq->nr_running > rq->nr_preferred_running)
|
|
|
|
return remote;
|
|
|
|
return all;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline enum fbq_type fbq_classify_group(struct sg_lb_stats *sgs)
|
|
|
|
{
|
|
|
|
return all;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline enum fbq_type fbq_classify_rq(struct rq *rq)
|
|
|
|
{
|
|
|
|
return regular;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_NUMA_BALANCING */
|
|
|
|
|
2019-10-18 13:26:38 +00:00
|
|
|
|
|
|
|
struct sg_lb_stats;
|
|
|
|
|
2019-10-22 16:46:38 +00:00
|
|
|
/*
|
|
|
|
* task_running_on_cpu - return 1 if @p is running on @cpu.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static unsigned int task_running_on_cpu(int cpu, struct task_struct *p)
|
|
|
|
{
|
|
|
|
/* Task has no contribution or is new */
|
|
|
|
if (cpu != task_cpu(p) || !READ_ONCE(p->se.avg.last_update_time))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (task_on_rq_queued(p))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* idle_cpu_without - would a given CPU be idle without p ?
|
|
|
|
* @cpu: the processor on which idleness is tested.
|
|
|
|
* @p: task which should be ignored.
|
|
|
|
*
|
|
|
|
* Return: 1 if the CPU would be idle. 0 otherwise.
|
|
|
|
*/
|
|
|
|
static int idle_cpu_without(int cpu, struct task_struct *p)
|
|
|
|
{
|
|
|
|
struct rq *rq = cpu_rq(cpu);
|
|
|
|
|
|
|
|
if (rq->curr != rq->idle && rq->curr != p)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* rq->nr_running can't be used but an updated version without the
|
|
|
|
* impact of p on cpu must be used instead. The updated nr_running
|
|
|
|
* be computed and tested before calling idle_cpu_without().
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
if (!llist_empty(&rq->wake_list))
|
|
|
|
return 0;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2019-10-18 13:26:38 +00:00
|
|
|
/*
|
|
|
|
* update_sg_wakeup_stats - Update sched_group's statistics for wakeup.
|
2019-10-22 16:46:38 +00:00
|
|
|
* @sd: The sched_domain level to look for idlest group.
|
2019-10-18 13:26:38 +00:00
|
|
|
* @group: sched_group whose statistics are to be updated.
|
|
|
|
* @sgs: variable to hold the statistics for this group.
|
2019-10-22 16:46:38 +00:00
|
|
|
* @p: The task for which we look for the idlest group/CPU.
|
2019-10-18 13:26:38 +00:00
|
|
|
*/
|
|
|
|
static inline void update_sg_wakeup_stats(struct sched_domain *sd,
|
|
|
|
struct sched_group *group,
|
|
|
|
struct sg_lb_stats *sgs,
|
|
|
|
struct task_struct *p)
|
|
|
|
{
|
|
|
|
int i, nr_running;
|
|
|
|
|
|
|
|
memset(sgs, 0, sizeof(*sgs));
|
|
|
|
|
|
|
|
for_each_cpu(i, sched_group_span(group)) {
|
|
|
|
struct rq *rq = cpu_rq(i);
|
2019-10-22 16:46:38 +00:00
|
|
|
unsigned int local;
|
2019-10-18 13:26:38 +00:00
|
|
|
|
2019-10-22 16:46:38 +00:00
|
|
|
sgs->group_load += cpu_load_without(rq, p);
|
2019-10-18 13:26:38 +00:00
|
|
|
sgs->group_util += cpu_util_without(i, p);
|
2019-10-22 16:46:38 +00:00
|
|
|
local = task_running_on_cpu(i, p);
|
|
|
|
sgs->sum_h_nr_running += rq->cfs.h_nr_running - local;
|
2019-10-18 13:26:38 +00:00
|
|
|
|
2019-10-22 16:46:38 +00:00
|
|
|
nr_running = rq->nr_running - local;
|
2019-10-18 13:26:38 +00:00
|
|
|
sgs->sum_nr_running += nr_running;
|
|
|
|
|
|
|
|
/*
|
2019-10-22 16:46:38 +00:00
|
|
|
* No need to call idle_cpu_without() if nr_running is not 0
|
2019-10-18 13:26:38 +00:00
|
|
|
*/
|
2019-10-22 16:46:38 +00:00
|
|
|
if (!nr_running && idle_cpu_without(i, p))
|
2019-10-18 13:26:38 +00:00
|
|
|
sgs->idle_cpus++;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if task fits in the group */
|
|
|
|
if (sd->flags & SD_ASYM_CPUCAPACITY &&
|
|
|
|
!task_fits_capacity(p, group->sgc->max_capacity)) {
|
|
|
|
sgs->group_misfit_task_load = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
sgs->group_capacity = group->sgc->capacity;
|
|
|
|
|
|
|
|
sgs->group_type = group_classify(sd->imbalance_pct, group, sgs);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Computing avg_load makes sense only when group is fully busy or
|
|
|
|
* overloaded
|
|
|
|
*/
|
|
|
|
if (sgs->group_type < group_fully_busy)
|
|
|
|
sgs->avg_load = (sgs->group_load * SCHED_CAPACITY_SCALE) /
|
|
|
|
sgs->group_capacity;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool update_pick_idlest(struct sched_group *idlest,
|
|
|
|
struct sg_lb_stats *idlest_sgs,
|
|
|
|
struct sched_group *group,
|
|
|
|
struct sg_lb_stats *sgs)
|
|
|
|
{
|
|
|
|
if (sgs->group_type < idlest_sgs->group_type)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (sgs->group_type > idlest_sgs->group_type)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The candidate and the current idlest group are the same type of
|
|
|
|
* group. Let check which one is the idlest according to the type.
|
|
|
|
*/
|
|
|
|
|
|
|
|
switch (sgs->group_type) {
|
|
|
|
case group_overloaded:
|
|
|
|
case group_fully_busy:
|
|
|
|
/* Select the group with lowest avg_load. */
|
|
|
|
if (idlest_sgs->avg_load <= sgs->avg_load)
|
|
|
|
return false;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case group_imbalanced:
|
|
|
|
case group_asym_packing:
|
|
|
|
/* Those types are not used in the slow wakeup path */
|
|
|
|
return false;
|
|
|
|
|
|
|
|
case group_misfit_task:
|
|
|
|
/* Select group with the highest max capacity */
|
|
|
|
if (idlest->sgc->max_capacity >= group->sgc->max_capacity)
|
|
|
|
return false;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case group_has_spare:
|
|
|
|
/* Select group with most idle CPUs */
|
|
|
|
if (idlest_sgs->idle_cpus >= sgs->idle_cpus)
|
|
|
|
return false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* find_idlest_group() finds and returns the least busy CPU group within the
|
|
|
|
* domain.
|
|
|
|
*
|
|
|
|
* Assumes p is allowed on at least one CPU in sd.
|
|
|
|
*/
|
|
|
|
static struct sched_group *
|
|
|
|
find_idlest_group(struct sched_domain *sd, struct task_struct *p,
|
|
|
|
int this_cpu, int sd_flag)
|
|
|
|
{
|
|
|
|
struct sched_group *idlest = NULL, *local = NULL, *group = sd->groups;
|
|
|
|
struct sg_lb_stats local_sgs, tmp_sgs;
|
|
|
|
struct sg_lb_stats *sgs;
|
|
|
|
unsigned long imbalance;
|
|
|
|
struct sg_lb_stats idlest_sgs = {
|
|
|
|
.avg_load = UINT_MAX,
|
|
|
|
.group_type = group_overloaded,
|
|
|
|
};
|
|
|
|
|
|
|
|
imbalance = scale_load_down(NICE_0_LOAD) *
|
|
|
|
(sd->imbalance_pct-100) / 100;
|
|
|
|
|
|
|
|
do {
|
|
|
|
int local_group;
|
|
|
|
|
|
|
|
/* Skip over this group if it has no CPUs allowed */
|
|
|
|
if (!cpumask_intersects(sched_group_span(group),
|
|
|
|
p->cpus_ptr))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
local_group = cpumask_test_cpu(this_cpu,
|
|
|
|
sched_group_span(group));
|
|
|
|
|
|
|
|
if (local_group) {
|
|
|
|
sgs = &local_sgs;
|
|
|
|
local = group;
|
|
|
|
} else {
|
|
|
|
sgs = &tmp_sgs;
|
|
|
|
}
|
|
|
|
|
|
|
|
update_sg_wakeup_stats(sd, group, sgs, p);
|
|
|
|
|
|
|
|
if (!local_group && update_pick_idlest(idlest, &idlest_sgs, group, sgs)) {
|
|
|
|
idlest = group;
|
|
|
|
idlest_sgs = *sgs;
|
|
|
|
}
|
|
|
|
|
|
|
|
} while (group = group->next, group != sd->groups);
|
|
|
|
|
|
|
|
|
|
|
|
/* There is no idlest group to push tasks to */
|
|
|
|
if (!idlest)
|
|
|
|
return NULL;
|
|
|
|
|
2019-12-04 18:21:40 +00:00
|
|
|
/* The local group has been skipped because of CPU affinity */
|
|
|
|
if (!local)
|
|
|
|
return idlest;
|
|
|
|
|
2019-10-18 13:26:38 +00:00
|
|
|
/*
|
|
|
|
* If the local group is idler than the selected idlest group
|
|
|
|
* don't try and push the task.
|
|
|
|
*/
|
|
|
|
if (local_sgs.group_type < idlest_sgs.group_type)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the local group is busier than the selected idlest group
|
|
|
|
* try and push the task.
|
|
|
|
*/
|
|
|
|
if (local_sgs.group_type > idlest_sgs.group_type)
|
|
|
|
return idlest;
|
|
|
|
|
|
|
|
switch (local_sgs.group_type) {
|
|
|
|
case group_overloaded:
|
|
|
|
case group_fully_busy:
|
|
|
|
/*
|
|
|
|
* When comparing groups across NUMA domains, it's possible for
|
|
|
|
* the local domain to be very lightly loaded relative to the
|
|
|
|
* remote domains but "imbalance" skews the comparison making
|
|
|
|
* remote CPUs look much more favourable. When considering
|
|
|
|
* cross-domain, add imbalance to the load on the remote node
|
|
|
|
* and consider staying local.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if ((sd->flags & SD_NUMA) &&
|
|
|
|
((idlest_sgs.avg_load + imbalance) >= local_sgs.avg_load))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the local group is less loaded than the selected
|
|
|
|
* idlest group don't try and push any tasks.
|
|
|
|
*/
|
|
|
|
if (idlest_sgs.avg_load >= (local_sgs.avg_load + imbalance))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
if (100 * local_sgs.avg_load <= sd->imbalance_pct * idlest_sgs.avg_load)
|
|
|
|
return NULL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case group_imbalanced:
|
|
|
|
case group_asym_packing:
|
|
|
|
/* Those type are not used in the slow wakeup path */
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
case group_misfit_task:
|
|
|
|
/* Select group with the highest max capacity */
|
|
|
|
if (local->sgc->max_capacity >= idlest->sgc->max_capacity)
|
|
|
|
return NULL;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case group_has_spare:
|
|
|
|
if (sd->flags & SD_NUMA) {
|
|
|
|
#ifdef CONFIG_NUMA_BALANCING
|
|
|
|
int idlest_cpu;
|
|
|
|
/*
|
|
|
|
* If there is spare capacity at NUMA, try to select
|
|
|
|
* the preferred node
|
|
|
|
*/
|
|
|
|
if (cpu_to_node(this_cpu) == p->numa_preferred_nid)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
idlest_cpu = cpumask_first(sched_group_span(idlest));
|
|
|
|
if (cpu_to_node(idlest_cpu) == p->numa_preferred_nid)
|
|
|
|
return idlest;
|
|
|
|
#endif
|
|
|
|
/*
|
|
|
|
* Otherwise, keep the task on this node to stay close
|
|
|
|
* its wakeup source and improve locality. If there is
|
|
|
|
* a real need of migration, periodic load balance will
|
|
|
|
* take care of it.
|
|
|
|
*/
|
|
|
|
if (local_sgs.idle_cpus)
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Select group with highest number of idle CPUs. We could also
|
|
|
|
* compare the utilization which is more stable but it can end
|
|
|
|
* up that the group has less spare capacity but finally more
|
|
|
|
* idle CPUs which means more opportunity to run task.
|
|
|
|
*/
|
|
|
|
if (local_sgs.idle_cpus >= idlest_sgs.idle_cpus)
|
|
|
|
return NULL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return idlest;
|
|
|
|
}
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/**
|
2011-10-12 03:00:59 +00:00
|
|
|
* update_sd_lb_stats - Update sched_domain's statistics for load balancing.
|
2012-06-08 20:18:33 +00:00
|
|
|
* @env: The load balancing environment.
|
2009-12-17 16:00:43 +00:00
|
|
|
* @sds: variable to hold the statistics for this sched_domain.
|
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
|
2013-10-07 10:29:33 +00:00
|
|
|
static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sds)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2012-05-02 12:20:37 +00:00
|
|
|
struct sched_domain *child = env->sd->child;
|
|
|
|
struct sched_group *sg = env->sd->groups;
|
sched/fair: Prefer sibiling only if local group is under-utilized
If the child domain prefers tasks to go siblings, the local group could
end up pulling tasks to itself even if the local group is almost equally
loaded as the source group.
Lets assume a 4 core,smt==2 machine running 5 thread ebizzy workload.
Everytime, local group has capacity and source group has atleast 2 threads,
local group tries to pull the task. This causes the threads to constantly
move between different cores. This is even more profound if the cores have
more threads, like in Power 8, smt 8 mode.
Fix this by only allowing local group to pull a task, if the source group
has more number of tasks than the local group.
Here are the relevant perf stat numbers of a 22 core,smt 8 Power 8 machine.
Without patch:
Performance counter stats for 'ebizzy -t 22 -S 100' (5 runs):
1,440 context-switches # 0.001 K/sec ( +- 1.26% )
366 cpu-migrations # 0.000 K/sec ( +- 5.58% )
3,933 page-faults # 0.002 K/sec ( +- 11.08% )
Performance counter stats for 'ebizzy -t 48 -S 100' (5 runs):
6,287 context-switches # 0.001 K/sec ( +- 3.65% )
3,776 cpu-migrations # 0.001 K/sec ( +- 4.84% )
5,702 page-faults # 0.001 K/sec ( +- 9.36% )
Performance counter stats for 'ebizzy -t 96 -S 100' (5 runs):
8,776 context-switches # 0.001 K/sec ( +- 0.73% )
2,790 cpu-migrations # 0.000 K/sec ( +- 0.98% )
10,540 page-faults # 0.001 K/sec ( +- 3.12% )
With patch:
Performance counter stats for 'ebizzy -t 22 -S 100' (5 runs):
1,133 context-switches # 0.001 K/sec ( +- 4.72% )
123 cpu-migrations # 0.000 K/sec ( +- 3.42% )
3,858 page-faults # 0.002 K/sec ( +- 8.52% )
Performance counter stats for 'ebizzy -t 48 -S 100' (5 runs):
2,169 context-switches # 0.000 K/sec ( +- 6.19% )
189 cpu-migrations # 0.000 K/sec ( +- 12.75% )
5,917 page-faults # 0.001 K/sec ( +- 8.09% )
Performance counter stats for 'ebizzy -t 96 -S 100' (5 runs):
5,333 context-switches # 0.001 K/sec ( +- 5.91% )
506 cpu-migrations # 0.000 K/sec ( +- 3.35% )
10,792 page-faults # 0.001 K/sec ( +- 7.75% )
Which show that in these workloads CPU migrations get reduced significantly.
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Link: http://lkml.kernel.org/r/1490205470-10249-1-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-22 17:57:50 +00:00
|
|
|
struct sg_lb_stats *local = &sds->local_stat;
|
2013-08-06 08:36:43 +00:00
|
|
|
struct sg_lb_stats tmp_sgs;
|
2018-12-03 09:56:24 +00:00
|
|
|
int sg_status = 0;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2017-12-21 10:20:23 +00:00
|
|
|
#ifdef CONFIG_NO_HZ_COMMON
|
2018-02-13 10:31:17 +00:00
|
|
|
if (env->idle == CPU_NEWLY_IDLE && READ_ONCE(nohz.has_blocked))
|
2017-12-21 10:20:23 +00:00
|
|
|
env->flags |= LBF_NOHZ_STATS;
|
|
|
|
#endif
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
do {
|
2013-08-06 08:36:43 +00:00
|
|
|
struct sg_lb_stats *sgs = &tmp_sgs;
|
2009-12-17 16:00:43 +00:00
|
|
|
int local_group;
|
|
|
|
|
2017-05-01 09:03:12 +00:00
|
|
|
local_group = cpumask_test_cpu(env->dst_cpu, sched_group_span(sg));
|
2013-08-06 08:36:43 +00:00
|
|
|
if (local_group) {
|
|
|
|
sds->local = sg;
|
sched/fair: Prefer sibiling only if local group is under-utilized
If the child domain prefers tasks to go siblings, the local group could
end up pulling tasks to itself even if the local group is almost equally
loaded as the source group.
Lets assume a 4 core,smt==2 machine running 5 thread ebizzy workload.
Everytime, local group has capacity and source group has atleast 2 threads,
local group tries to pull the task. This causes the threads to constantly
move between different cores. This is even more profound if the cores have
more threads, like in Power 8, smt 8 mode.
Fix this by only allowing local group to pull a task, if the source group
has more number of tasks than the local group.
Here are the relevant perf stat numbers of a 22 core,smt 8 Power 8 machine.
Without patch:
Performance counter stats for 'ebizzy -t 22 -S 100' (5 runs):
1,440 context-switches # 0.001 K/sec ( +- 1.26% )
366 cpu-migrations # 0.000 K/sec ( +- 5.58% )
3,933 page-faults # 0.002 K/sec ( +- 11.08% )
Performance counter stats for 'ebizzy -t 48 -S 100' (5 runs):
6,287 context-switches # 0.001 K/sec ( +- 3.65% )
3,776 cpu-migrations # 0.001 K/sec ( +- 4.84% )
5,702 page-faults # 0.001 K/sec ( +- 9.36% )
Performance counter stats for 'ebizzy -t 96 -S 100' (5 runs):
8,776 context-switches # 0.001 K/sec ( +- 0.73% )
2,790 cpu-migrations # 0.000 K/sec ( +- 0.98% )
10,540 page-faults # 0.001 K/sec ( +- 3.12% )
With patch:
Performance counter stats for 'ebizzy -t 22 -S 100' (5 runs):
1,133 context-switches # 0.001 K/sec ( +- 4.72% )
123 cpu-migrations # 0.000 K/sec ( +- 3.42% )
3,858 page-faults # 0.002 K/sec ( +- 8.52% )
Performance counter stats for 'ebizzy -t 48 -S 100' (5 runs):
2,169 context-switches # 0.000 K/sec ( +- 6.19% )
189 cpu-migrations # 0.000 K/sec ( +- 12.75% )
5,917 page-faults # 0.001 K/sec ( +- 8.09% )
Performance counter stats for 'ebizzy -t 96 -S 100' (5 runs):
5,333 context-switches # 0.001 K/sec ( +- 5.91% )
506 cpu-migrations # 0.000 K/sec ( +- 3.35% )
10,792 page-faults # 0.001 K/sec ( +- 7.75% )
Which show that in these workloads CPU migrations get reduced significantly.
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Link: http://lkml.kernel.org/r/1490205470-10249-1-git-send-email-srikar@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-03-22 17:57:50 +00:00
|
|
|
sgs = local;
|
2013-08-28 08:32:32 +00:00
|
|
|
|
|
|
|
if (env->idle != CPU_NEWLY_IDLE ||
|
2014-05-26 22:19:37 +00:00
|
|
|
time_after_eq(jiffies, sg->sgc->next_update))
|
|
|
|
update_group_capacity(env->sd, env->dst_cpu);
|
2013-08-06 08:36:43 +00:00
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2018-12-03 09:56:24 +00:00
|
|
|
update_sg_lb_stats(env, sg, sgs, &sg_status);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2013-08-28 08:32:32 +00:00
|
|
|
if (local_group)
|
|
|
|
goto next_group;
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2013-08-28 08:32:32 +00:00
|
|
|
if (update_sd_pick_busiest(env, sds, sg, sgs)) {
|
2010-06-08 04:57:02 +00:00
|
|
|
sds->busiest = sg;
|
2013-08-06 08:36:43 +00:00
|
|
|
sds->busiest_stat = *sgs;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2013-08-28 08:32:32 +00:00
|
|
|
next_group:
|
|
|
|
/* Now, start updating sd_lb_stats */
|
|
|
|
sds->total_load += sgs->group_load;
|
2014-05-26 22:19:37 +00:00
|
|
|
sds->total_capacity += sgs->group_capacity;
|
2013-08-28 08:32:32 +00:00
|
|
|
|
2010-06-08 04:57:02 +00:00
|
|
|
sg = sg->next;
|
2012-05-02 12:20:37 +00:00
|
|
|
} while (sg != env->sd->groups);
|
2013-10-07 10:29:33 +00:00
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
/* Tag domain that child domain prefers tasks go to siblings first */
|
|
|
|
sds->prefer_sibling = child && child->flags & SD_PREFER_SIBLING;
|
|
|
|
|
2018-02-13 10:31:17 +00:00
|
|
|
#ifdef CONFIG_NO_HZ_COMMON
|
|
|
|
if ((env->flags & LBF_NOHZ_AGAIN) &&
|
|
|
|
cpumask_subset(nohz.idle_cpus_mask, sched_domain_span(env->sd))) {
|
|
|
|
|
|
|
|
WRITE_ONCE(nohz.next_blocked,
|
|
|
|
jiffies + msecs_to_jiffies(LOAD_AVG_PERIOD));
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2013-10-07 10:29:33 +00:00
|
|
|
if (env->sd->flags & SD_NUMA)
|
|
|
|
env->fbq_type = fbq_classify_group(&sds->busiest_stat);
|
2014-06-23 19:16:49 +00:00
|
|
|
|
|
|
|
if (!env->sd->parent) {
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
struct root_domain *rd = env->dst_rq->rd;
|
|
|
|
|
2014-06-23 19:16:49 +00:00
|
|
|
/* update overload indicator if we are at root domain */
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
WRITE_ONCE(rd->overload, sg_status & SG_OVERLOAD);
|
|
|
|
|
|
|
|
/* Update over-utilization (tipping point, U >= 0) indicator */
|
|
|
|
WRITE_ONCE(rd->overutilized, sg_status & SG_OVERUTILIZED);
|
2019-06-04 11:14:58 +00:00
|
|
|
trace_sched_overutilized_tp(rd, sg_status & SG_OVERUTILIZED);
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
} else if (sg_status & SG_OVERUTILIZED) {
|
2019-06-04 11:14:58 +00:00
|
|
|
struct root_domain *rd = env->dst_rq->rd;
|
|
|
|
|
|
|
|
WRITE_ONCE(rd->overutilized, SG_OVERUTILIZED);
|
|
|
|
trace_sched_overutilized_tp(rd, SG_OVERUTILIZED);
|
2014-06-23 19:16:49 +00:00
|
|
|
}
|
2010-06-08 04:57:02 +00:00
|
|
|
}
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/**
|
|
|
|
* calculate_imbalance - Calculate the amount of imbalance present within the
|
|
|
|
* groups of a given sched_domain during load balance.
|
2012-05-02 12:20:37 +00:00
|
|
|
* @env: load balance environment
|
2009-12-17 16:00:43 +00:00
|
|
|
* @sds: statistics of the sched_domain whose imbalance is to be calculated.
|
|
|
|
*/
|
2012-05-02 12:20:37 +00:00
|
|
|
static inline void calculate_imbalance(struct lb_env *env, struct sd_lb_stats *sds)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2013-08-06 08:36:43 +00:00
|
|
|
struct sg_lb_stats *local, *busiest;
|
|
|
|
|
|
|
|
local = &sds->local_stat;
|
|
|
|
busiest = &sds->busiest_stat;
|
2010-02-24 00:13:52 +00:00
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
if (busiest->group_type == group_misfit_task) {
|
|
|
|
/* Set imbalance to allow misfit tasks to be balanced. */
|
|
|
|
env->migration_type = migrate_misfit;
|
2019-10-18 13:26:35 +00:00
|
|
|
env->imbalance = 1;
|
2019-10-18 13:26:31 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (busiest->group_type == group_asym_packing) {
|
|
|
|
/*
|
|
|
|
* In case of asym capacity, we will try to migrate all load to
|
|
|
|
* the preferred CPU.
|
|
|
|
*/
|
|
|
|
env->migration_type = migrate_task;
|
|
|
|
env->imbalance = busiest->sum_h_nr_running;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (busiest->group_type == group_imbalanced) {
|
|
|
|
/*
|
|
|
|
* In the group_imb case we cannot rely on group-wide averages
|
|
|
|
* to ensure CPU-load equilibrium, try to move any task to fix
|
|
|
|
* the imbalance. The next load balance will take care of
|
|
|
|
* balancing back the system.
|
|
|
|
*/
|
|
|
|
env->migration_type = migrate_task;
|
|
|
|
env->imbalance = 1;
|
2019-10-18 13:26:28 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/*
|
2019-10-18 13:26:31 +00:00
|
|
|
* Try to use spare capacity of local group without overloading it or
|
2019-11-12 14:50:43 +00:00
|
|
|
* emptying busiest.
|
|
|
|
* XXX Spreading tasks across NUMA nodes is not always the best policy
|
|
|
|
* and special care should be taken for SD_NUMA domain level before
|
|
|
|
* spreading the tasks. For now, load_balance() fully relies on
|
|
|
|
* NUMA_BALANCING and fbq_classify_group/rq to override the decision.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
if (local->group_type == group_has_spare) {
|
|
|
|
if (busiest->group_type > group_fully_busy) {
|
|
|
|
/*
|
|
|
|
* If busiest is overloaded, try to fill spare
|
|
|
|
* capacity. This might end up creating spare capacity
|
|
|
|
* in busiest or busiest still being overloaded but
|
|
|
|
* there is no simple way to directly compute the
|
|
|
|
* amount of load to migrate in order to balance the
|
|
|
|
* system.
|
|
|
|
*/
|
|
|
|
env->migration_type = migrate_util;
|
|
|
|
env->imbalance = max(local->group_capacity, local->group_util) -
|
|
|
|
local->group_util;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In some cases, the group's utilization is max or even
|
|
|
|
* higher than capacity because of migrations but the
|
|
|
|
* local CPU is (newly) idle. There is at least one
|
|
|
|
* waiting task in this overloaded busiest group. Let's
|
|
|
|
* try to pull it.
|
|
|
|
*/
|
|
|
|
if (env->idle != CPU_NOT_IDLE && env->imbalance == 0) {
|
|
|
|
env->migration_type = migrate_task;
|
|
|
|
env->imbalance = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (busiest->group_weight == 1 || sds->prefer_sibling) {
|
2019-10-18 13:26:32 +00:00
|
|
|
unsigned int nr_diff = busiest->sum_nr_running;
|
2019-10-18 13:26:31 +00:00
|
|
|
/*
|
|
|
|
* When prefer sibling, evenly spread running tasks on
|
|
|
|
* groups.
|
|
|
|
*/
|
|
|
|
env->migration_type = migrate_task;
|
2019-10-18 13:26:32 +00:00
|
|
|
lsub_positive(&nr_diff, local->sum_nr_running);
|
2019-10-18 13:26:31 +00:00
|
|
|
env->imbalance = nr_diff >> 1;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If there is no overload, we just want to even the number of
|
|
|
|
* idle cpus.
|
|
|
|
*/
|
|
|
|
env->migration_type = migrate_task;
|
|
|
|
env->imbalance = max_t(long, 0, (local->idle_cpus -
|
|
|
|
busiest->idle_cpus) >> 1);
|
2019-10-18 13:26:30 +00:00
|
|
|
return;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2014-07-29 15:15:11 +00:00
|
|
|
/*
|
2019-10-18 13:26:31 +00:00
|
|
|
* Local is fully busy but has to take more load to relieve the
|
|
|
|
* busiest group
|
2014-07-29 15:15:11 +00:00
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
if (local->group_type < group_overloaded) {
|
|
|
|
/*
|
|
|
|
* Local will become overloaded so the avg_load metrics are
|
|
|
|
* finally needed.
|
|
|
|
*/
|
|
|
|
|
|
|
|
local->avg_load = (local->group_load * SCHED_CAPACITY_SCALE) /
|
|
|
|
local->group_capacity;
|
|
|
|
|
|
|
|
sds->avg_load = (sds->total_load * SCHED_CAPACITY_SCALE) /
|
|
|
|
sds->total_capacity;
|
2010-02-24 00:13:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2019-10-18 13:26:31 +00:00
|
|
|
* Both group are or will become overloaded and we're trying to get all
|
|
|
|
* the CPUs to the average_load, so we don't want to push ourselves
|
|
|
|
* above the average load, nor do we wish to reduce the max loaded CPU
|
|
|
|
* below the average load. At the same time, we also don't want to
|
|
|
|
* reduce the group load below the group capacity. Thus we look for
|
|
|
|
* the minimum possible imbalance.
|
2010-02-24 00:13:52 +00:00
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
env->migration_type = migrate_load;
|
2013-08-06 08:36:43 +00:00
|
|
|
env->imbalance = min(
|
2019-10-18 13:26:31 +00:00
|
|
|
(busiest->avg_load - sds->avg_load) * busiest->group_capacity,
|
2014-05-26 22:19:37 +00:00
|
|
|
(sds->avg_load - local->avg_load) * local->group_capacity
|
2014-05-26 22:19:39 +00:00
|
|
|
) / SCHED_CAPACITY_SCALE;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
2010-10-15 20:12:29 +00:00
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/******* find_busiest_group() helpers end here *********************/
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
/*
|
|
|
|
* Decision matrix according to the local and busiest group type:
|
|
|
|
*
|
|
|
|
* busiest \ local has_spare fully_busy misfit asym imbalanced overloaded
|
|
|
|
* has_spare nr_idle balanced N/A N/A balanced balanced
|
|
|
|
* fully_busy nr_idle nr_idle N/A N/A balanced balanced
|
|
|
|
* misfit_task force N/A N/A N/A force force
|
|
|
|
* asym_packing force force N/A N/A force force
|
|
|
|
* imbalanced force force N/A N/A force force
|
|
|
|
* overloaded force force N/A N/A force avg_load
|
|
|
|
*
|
|
|
|
* N/A : Not Applicable because already filtered while updating
|
|
|
|
* statistics.
|
|
|
|
* balanced : The system is balanced for these 2 groups.
|
|
|
|
* force : Calculate the imbalance as load migration is probably needed.
|
|
|
|
* avg_load : Only if imbalance is significant enough.
|
|
|
|
* nr_idle : dst_cpu is not busy and the number of idle CPUs is quite
|
|
|
|
* different in groups.
|
|
|
|
*/
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/**
|
|
|
|
* find_busiest_group - Returns the busiest group within the sched_domain
|
2016-04-29 19:32:38 +00:00
|
|
|
* if there is an imbalance.
|
2009-12-17 16:00:43 +00:00
|
|
|
*
|
2019-06-18 12:23:10 +00:00
|
|
|
* Also calculates the amount of runnable load which should be moved
|
2009-12-17 16:00:43 +00:00
|
|
|
* to restore balance.
|
|
|
|
*
|
2012-06-08 20:18:33 +00:00
|
|
|
* @env: The load balancing environment.
|
2009-12-17 16:00:43 +00:00
|
|
|
*
|
2013-07-12 18:45:47 +00:00
|
|
|
* Return: - The busiest group if imbalance exists.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2013-08-06 08:36:43 +00:00
|
|
|
static struct sched_group *find_busiest_group(struct lb_env *env)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2013-08-06 08:36:43 +00:00
|
|
|
struct sg_lb_stats *local, *busiest;
|
2009-12-17 16:00:43 +00:00
|
|
|
struct sd_lb_stats sds;
|
|
|
|
|
2013-08-19 13:22:57 +00:00
|
|
|
init_sd_lb_stats(&sds);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
|
|
|
/*
|
2019-10-18 13:26:33 +00:00
|
|
|
* Compute the various statistics relevant for load balancing at
|
2009-12-17 16:00:43 +00:00
|
|
|
* this level.
|
|
|
|
*/
|
2013-08-06 08:36:42 +00:00
|
|
|
update_sd_lb_stats(env, &sds);
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
|
2018-12-05 10:23:56 +00:00
|
|
|
if (sched_energy_enabled()) {
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
struct root_domain *rd = env->dst_rq->rd;
|
|
|
|
|
|
|
|
if (rcu_dereference(rd->pd) && !READ_ONCE(rd->overutilized))
|
|
|
|
goto out_balanced;
|
|
|
|
}
|
|
|
|
|
2013-08-06 08:36:43 +00:00
|
|
|
local = &sds.local_stat;
|
|
|
|
busiest = &sds.busiest_stat;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2011-02-21 17:55:32 +00:00
|
|
|
/* There is no busy sibling group to pull tasks from */
|
2019-10-18 13:26:31 +00:00
|
|
|
if (!sds.busiest)
|
2009-12-17 16:00:43 +00:00
|
|
|
goto out_balanced;
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
/* Misfit tasks should be dealt with regardless of the avg load */
|
|
|
|
if (busiest->group_type == group_misfit_task)
|
|
|
|
goto force_balance;
|
|
|
|
|
|
|
|
/* ASYM feature bypasses nice load balance check */
|
|
|
|
if (busiest->group_type == group_asym_packing)
|
|
|
|
goto force_balance;
|
2011-04-08 00:23:22 +00:00
|
|
|
|
2011-02-21 17:56:47 +00:00
|
|
|
/*
|
|
|
|
* If the busiest group is imbalanced the below checks don't
|
2013-08-15 18:29:29 +00:00
|
|
|
* work because they assume all things are equal, which typically
|
2019-04-23 14:26:36 +00:00
|
|
|
* isn't true due to cpus_ptr constraints and the like.
|
2011-02-21 17:56:47 +00:00
|
|
|
*/
|
2014-07-28 18:16:28 +00:00
|
|
|
if (busiest->group_type == group_imbalanced)
|
2011-02-21 17:56:47 +00:00
|
|
|
goto force_balance;
|
|
|
|
|
2011-02-21 17:55:32 +00:00
|
|
|
/*
|
2014-09-21 01:24:36 +00:00
|
|
|
* If the local group is busier than the selected busiest group
|
2011-02-21 17:55:32 +00:00
|
|
|
* don't try and pull any tasks.
|
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
if (local->group_type > busiest->group_type)
|
2009-12-17 16:00:43 +00:00
|
|
|
goto out_balanced;
|
|
|
|
|
2011-02-21 17:55:32 +00:00
|
|
|
/*
|
2019-10-18 13:26:31 +00:00
|
|
|
* When groups are overloaded, use the avg_load to ensure fairness
|
|
|
|
* between tasks.
|
2011-02-21 17:55:32 +00:00
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
if (local->group_type == group_overloaded) {
|
|
|
|
/*
|
|
|
|
* If the local group is more loaded than the selected
|
|
|
|
* busiest group don't try to pull any tasks.
|
|
|
|
*/
|
|
|
|
if (local->avg_load >= busiest->avg_load)
|
|
|
|
goto out_balanced;
|
|
|
|
|
|
|
|
/* XXX broken for overlapping NUMA groups */
|
|
|
|
sds.avg_load = (sds.total_load * SCHED_CAPACITY_SCALE) /
|
|
|
|
sds.total_capacity;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2010-09-17 22:02:32 +00:00
|
|
|
/*
|
2019-10-18 13:26:31 +00:00
|
|
|
* Don't pull any tasks if this group is already above the
|
|
|
|
* domain average load.
|
2010-09-17 22:02:32 +00:00
|
|
|
*/
|
2019-10-18 13:26:31 +00:00
|
|
|
if (local->avg_load >= sds.avg_load)
|
2010-09-17 22:02:32 +00:00
|
|
|
goto out_balanced;
|
2019-10-18 13:26:31 +00:00
|
|
|
|
2011-02-21 17:52:53 +00:00
|
|
|
/*
|
2019-10-18 13:26:31 +00:00
|
|
|
* If the busiest group is more loaded, use imbalance_pct to be
|
|
|
|
* conservative.
|
2011-02-21 17:52:53 +00:00
|
|
|
*/
|
2013-08-06 08:36:43 +00:00
|
|
|
if (100 * busiest->avg_load <=
|
|
|
|
env->sd->imbalance_pct * local->avg_load)
|
2011-02-21 17:52:53 +00:00
|
|
|
goto out_balanced;
|
2010-09-17 22:02:32 +00:00
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
/* Try to move all excess tasks to child's sibling domain */
|
|
|
|
if (sds.prefer_sibling && local->group_type == group_has_spare &&
|
2019-10-18 13:26:32 +00:00
|
|
|
busiest->sum_nr_running > local->sum_nr_running + 1)
|
2019-10-18 13:26:31 +00:00
|
|
|
goto force_balance;
|
|
|
|
|
2019-10-18 13:26:34 +00:00
|
|
|
if (busiest->group_type != group_overloaded) {
|
|
|
|
if (env->idle == CPU_NOT_IDLE)
|
|
|
|
/*
|
|
|
|
* If the busiest group is not overloaded (and as a
|
|
|
|
* result the local one too) but this CPU is already
|
|
|
|
* busy, let another idle CPU try to pull task.
|
|
|
|
*/
|
|
|
|
goto out_balanced;
|
|
|
|
|
|
|
|
if (busiest->group_weight > 1 &&
|
|
|
|
local->idle_cpus <= (busiest->idle_cpus + 1))
|
|
|
|
/*
|
|
|
|
* If the busiest group is not overloaded
|
|
|
|
* and there is no imbalance between this and busiest
|
|
|
|
* group wrt idle CPUs, it is balanced. The imbalance
|
|
|
|
* becomes significant if the diff is greater than 1
|
|
|
|
* otherwise we might end up to just move the imbalance
|
|
|
|
* on another group. Of course this applies only if
|
|
|
|
* there is more than 1 CPU per group.
|
|
|
|
*/
|
|
|
|
goto out_balanced;
|
|
|
|
|
|
|
|
if (busiest->sum_h_nr_running == 1)
|
|
|
|
/*
|
|
|
|
* busiest doesn't have any tasks waiting to run
|
|
|
|
*/
|
|
|
|
goto out_balanced;
|
|
|
|
}
|
2019-10-18 13:26:31 +00:00
|
|
|
|
2010-10-15 20:12:29 +00:00
|
|
|
force_balance:
|
2009-12-17 16:00:43 +00:00
|
|
|
/* Looks like there is an imbalance. Compute it */
|
2012-05-02 12:20:37 +00:00
|
|
|
calculate_imbalance(env, &sds);
|
2018-09-07 07:51:04 +00:00
|
|
|
return env->imbalance ? sds.busiest : NULL;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
|
|
|
out_balanced:
|
2012-05-02 12:20:37 +00:00
|
|
|
env->imbalance = 0;
|
2009-12-17 16:00:43 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* find_busiest_queue - find the busiest runqueue among the CPUs in the group.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2012-05-02 12:20:37 +00:00
|
|
|
static struct rq *find_busiest_queue(struct lb_env *env,
|
2012-07-12 08:10:13 +00:00
|
|
|
struct sched_group *group)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
|
|
|
struct rq *busiest = NULL, *rq;
|
2019-10-18 13:26:31 +00:00
|
|
|
unsigned long busiest_util = 0, busiest_load = 0, busiest_capacity = 1;
|
|
|
|
unsigned int busiest_nr = 0;
|
2009-12-17 16:00:43 +00:00
|
|
|
int i;
|
|
|
|
|
2017-05-01 09:03:12 +00:00
|
|
|
for_each_cpu_and(i, sched_group_span(group), env->cpus) {
|
2019-10-18 13:26:31 +00:00
|
|
|
unsigned long capacity, load, util;
|
|
|
|
unsigned int nr_running;
|
2013-10-07 10:29:33 +00:00
|
|
|
enum fbq_type rt;
|
|
|
|
|
|
|
|
rq = cpu_rq(i);
|
|
|
|
rt = fbq_classify_rq(rq);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2013-10-07 10:29:33 +00:00
|
|
|
/*
|
|
|
|
* We classify groups/runqueues into three groups:
|
|
|
|
* - regular: there are !numa tasks
|
|
|
|
* - remote: there are numa tasks that run on the 'wrong' node
|
|
|
|
* - all: there is no distinction
|
|
|
|
*
|
|
|
|
* In order to avoid migrating ideally placed numa tasks,
|
|
|
|
* ignore those when there's better options.
|
|
|
|
*
|
|
|
|
* If we ignore the actual busiest queue to migrate another
|
|
|
|
* task, the next balance pass can still reduce the busiest
|
|
|
|
* queue by moving tasks around inside the node.
|
|
|
|
*
|
|
|
|
* If we cannot move enough load due to this classification
|
|
|
|
* the next pass will adjust the group classification and
|
|
|
|
* allow migration of more tasks.
|
|
|
|
*
|
|
|
|
* Both cases only affect the total convergence complexity.
|
|
|
|
*/
|
|
|
|
if (rt > env->fbq_type)
|
|
|
|
continue;
|
|
|
|
|
2014-05-26 22:19:38 +00:00
|
|
|
capacity = capacity_of(i);
|
2019-10-18 13:26:31 +00:00
|
|
|
nr_running = rq->cfs.h_nr_running;
|
2010-06-08 04:57:02 +00:00
|
|
|
|
2018-07-04 10:17:48 +00:00
|
|
|
/*
|
|
|
|
* For ASYM_CPUCAPACITY domains, don't pick a CPU that could
|
|
|
|
* eventually lead to active_balancing high->low capacity.
|
|
|
|
* Higher per-CPU capacity is considered better than balancing
|
|
|
|
* average load.
|
|
|
|
*/
|
|
|
|
if (env->sd->flags & SD_ASYM_CPUCAPACITY &&
|
|
|
|
capacity_of(env->dst_cpu) < capacity &&
|
2019-10-18 13:26:31 +00:00
|
|
|
nr_running == 1)
|
2018-07-04 10:17:48 +00:00
|
|
|
continue;
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
switch (env->migration_type) {
|
|
|
|
case migrate_load:
|
|
|
|
/*
|
2019-10-18 13:26:33 +00:00
|
|
|
* When comparing with load imbalance, use cpu_load()
|
|
|
|
* which is not scaled with the CPU capacity.
|
2019-10-18 13:26:31 +00:00
|
|
|
*/
|
2019-10-18 13:26:33 +00:00
|
|
|
load = cpu_load(rq);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
if (nr_running == 1 && load > env->imbalance &&
|
|
|
|
!check_cpu_capacity(rq, env->sd))
|
|
|
|
break;
|
2015-02-27 15:54:11 +00:00
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
/*
|
|
|
|
* For the load comparisons with the other CPUs,
|
2019-10-18 13:26:33 +00:00
|
|
|
* consider the cpu_load() scaled with the CPU
|
|
|
|
* capacity, so that the load can be moved away
|
|
|
|
* from the CPU that is potentially running at a
|
|
|
|
* lower capacity.
|
2019-10-18 13:26:31 +00:00
|
|
|
*
|
|
|
|
* Thus we're looking for max(load_i / capacity_i),
|
|
|
|
* crosswise multiplication to rid ourselves of the
|
|
|
|
* division works out to:
|
|
|
|
* load_i * capacity_j > load_j * capacity_i;
|
|
|
|
* where j is our previous maximum.
|
|
|
|
*/
|
|
|
|
if (load * busiest_capacity > busiest_load * capacity) {
|
|
|
|
busiest_load = load;
|
|
|
|
busiest_capacity = capacity;
|
|
|
|
busiest = rq;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case migrate_util:
|
|
|
|
util = cpu_util(cpu_of(rq));
|
|
|
|
|
|
|
|
if (busiest_util < util) {
|
|
|
|
busiest_util = util;
|
|
|
|
busiest = rq;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case migrate_task:
|
|
|
|
if (busiest_nr < nr_running) {
|
|
|
|
busiest_nr = nr_running;
|
|
|
|
busiest = rq;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case migrate_misfit:
|
|
|
|
/*
|
|
|
|
* For ASYM_CPUCAPACITY domains with misfit tasks we
|
|
|
|
* simply seek the "biggest" misfit task.
|
|
|
|
*/
|
|
|
|
if (rq->misfit_task_load > busiest_load) {
|
|
|
|
busiest_load = rq->misfit_task_load;
|
|
|
|
busiest = rq;
|
|
|
|
}
|
|
|
|
|
|
|
|
break;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return busiest;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Max backoff if we encounter pinned tasks. Pretty arbitrary value, but
|
|
|
|
* so long as it is large enough.
|
|
|
|
*/
|
|
|
|
#define MAX_PINNED_INTERVAL 512
|
|
|
|
|
2018-12-14 16:01:57 +00:00
|
|
|
static inline bool
|
|
|
|
asym_active_balance(struct lb_env *env)
|
2009-12-23 14:10:31 +00:00
|
|
|
{
|
2018-12-14 16:01:57 +00:00
|
|
|
/*
|
|
|
|
* ASYM_PACKING needs to force migrate tasks from busy but
|
|
|
|
* lower priority CPUs in order to pack all tasks in the
|
|
|
|
* highest priority CPUs.
|
|
|
|
*/
|
|
|
|
return env->idle != CPU_NOT_IDLE && (env->sd->flags & SD_ASYM_PACKING) &&
|
|
|
|
sched_asym_prefer(env->dst_cpu, env->src_cpu);
|
|
|
|
}
|
2012-05-02 12:20:37 +00:00
|
|
|
|
2018-12-14 16:01:57 +00:00
|
|
|
static inline bool
|
|
|
|
voluntary_active_balance(struct lb_env *env)
|
|
|
|
{
|
|
|
|
struct sched_domain *sd = env->sd;
|
2010-06-08 04:57:02 +00:00
|
|
|
|
2018-12-14 16:01:57 +00:00
|
|
|
if (asym_active_balance(env))
|
|
|
|
return 1;
|
2009-12-23 14:10:31 +00:00
|
|
|
|
2015-02-27 15:54:14 +00:00
|
|
|
/*
|
|
|
|
* The dst_cpu is idle and the src_cpu CPU has only 1 CFS task.
|
|
|
|
* It's worth migrating the task if the src_cpu's capacity is reduced
|
|
|
|
* because of other sched_class or IRQs if more capacity stays
|
|
|
|
* available on dst_cpu.
|
|
|
|
*/
|
|
|
|
if ((env->idle != CPU_NOT_IDLE) &&
|
|
|
|
(env->src_rq->cfs.h_nr_running == 1)) {
|
|
|
|
if ((check_cpu_capacity(env->src_rq, sd)) &&
|
|
|
|
(capacity_of(env->src_cpu)*sd->imbalance_pct < capacity_of(env->dst_cpu)*100))
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2019-10-18 13:26:31 +00:00
|
|
|
if (env->migration_type == migrate_misfit)
|
2018-07-04 10:17:42 +00:00
|
|
|
return 1;
|
|
|
|
|
2018-12-14 16:01:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int need_active_balance(struct lb_env *env)
|
|
|
|
{
|
|
|
|
struct sched_domain *sd = env->sd;
|
|
|
|
|
|
|
|
if (voluntary_active_balance(env))
|
|
|
|
return 1;
|
|
|
|
|
2009-12-23 14:10:31 +00:00
|
|
|
return unlikely(sd->nr_balance_failed > sd->cache_nice_tries+2);
|
|
|
|
}
|
|
|
|
|
2010-05-06 16:49:21 +00:00
|
|
|
static int active_load_balance_cpu_stop(void *data);
|
|
|
|
|
2013-08-06 08:36:42 +00:00
|
|
|
static int should_we_balance(struct lb_env *env)
|
|
|
|
{
|
|
|
|
struct sched_group *sg = env->sd->groups;
|
|
|
|
int cpu, balance_cpu = -1;
|
|
|
|
|
2017-10-09 08:36:53 +00:00
|
|
|
/*
|
|
|
|
* Ensure the balancing environment is consistent; can happen
|
|
|
|
* when the softirq triggers 'during' hotplug.
|
|
|
|
*/
|
|
|
|
if (!cpumask_test_cpu(env->dst_cpu, env->cpus))
|
|
|
|
return 0;
|
|
|
|
|
2013-08-06 08:36:42 +00:00
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* In the newly idle case, we will allow all the CPUs
|
2013-08-06 08:36:42 +00:00
|
|
|
* to do the newly idle load balance.
|
|
|
|
*/
|
|
|
|
if (env->idle == CPU_NEWLY_IDLE)
|
|
|
|
return 1;
|
|
|
|
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/* Try to find first idle CPU */
|
2017-05-01 08:47:02 +00:00
|
|
|
for_each_cpu_and(cpu, group_balance_mask(sg), env->cpus) {
|
2017-05-01 06:51:05 +00:00
|
|
|
if (!idle_cpu(cpu))
|
2013-08-06 08:36:42 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
balance_cpu = cpu;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (balance_cpu == -1)
|
|
|
|
balance_cpu = group_balance_cpu(sg);
|
|
|
|
|
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* First idle CPU or the first CPU(busiest) in this sched group
|
2013-08-06 08:36:42 +00:00
|
|
|
* is eligible for doing load balancing at this and above domains.
|
|
|
|
*/
|
2013-09-10 06:54:49 +00:00
|
|
|
return balance_cpu == env->dst_cpu;
|
2013-08-06 08:36:42 +00:00
|
|
|
}
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/*
|
|
|
|
* Check this_cpu to ensure it is balanced within domain. Attempt to move
|
|
|
|
* tasks if there is an imbalance.
|
|
|
|
*/
|
|
|
|
static int load_balance(int this_cpu, struct rq *this_rq,
|
|
|
|
struct sched_domain *sd, enum cpu_idle_type idle,
|
2013-08-06 08:36:42 +00:00
|
|
|
int *continue_balancing)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2012-06-19 12:13:15 +00:00
|
|
|
int ld_moved, cur_ld_moved, active_balance = 0;
|
2013-08-19 10:41:09 +00:00
|
|
|
struct sched_domain *sd_parent = sd->parent;
|
2009-12-17 16:00:43 +00:00
|
|
|
struct sched_group *group;
|
|
|
|
struct rq *busiest;
|
2016-10-04 14:04:35 +00:00
|
|
|
struct rq_flags rf;
|
2014-08-27 00:12:21 +00:00
|
|
|
struct cpumask *cpus = this_cpu_cpumask_var_ptr(load_balance_mask);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2012-02-22 11:47:19 +00:00
|
|
|
struct lb_env env = {
|
|
|
|
.sd = sd,
|
2012-02-22 18:27:40 +00:00
|
|
|
.dst_cpu = this_cpu,
|
|
|
|
.dst_rq = this_rq,
|
2017-05-01 09:03:12 +00:00
|
|
|
.dst_grpmask = sched_group_span(sd->groups),
|
2012-02-22 11:47:19 +00:00
|
|
|
.idle = idle,
|
2012-04-17 11:38:40 +00:00
|
|
|
.loop_break = sched_nr_migrate_break,
|
2012-07-12 08:10:13 +00:00
|
|
|
.cpus = cpus,
|
2013-10-07 10:29:33 +00:00
|
|
|
.fbq_type = all,
|
2014-08-20 09:48:29 +00:00
|
|
|
.tasks = LIST_HEAD_INIT(env.tasks),
|
2012-02-22 11:47:19 +00:00
|
|
|
};
|
|
|
|
|
2017-06-07 19:18:57 +00:00
|
|
|
cpumask_and(cpus, sched_domain_span(sd), cpu_active_mask);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(sd->lb_count[idle]);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
|
|
|
redo:
|
2013-08-06 08:36:42 +00:00
|
|
|
if (!should_we_balance(&env)) {
|
|
|
|
*continue_balancing = 0;
|
2009-12-17 16:00:43 +00:00
|
|
|
goto out_balanced;
|
2013-08-06 08:36:42 +00:00
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2013-08-06 08:36:42 +00:00
|
|
|
group = find_busiest_group(&env);
|
2009-12-17 16:00:43 +00:00
|
|
|
if (!group) {
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(sd->lb_nobusyg[idle]);
|
2009-12-17 16:00:43 +00:00
|
|
|
goto out_balanced;
|
|
|
|
}
|
|
|
|
|
2012-07-12 08:10:13 +00:00
|
|
|
busiest = find_busiest_queue(&env, group);
|
2009-12-17 16:00:43 +00:00
|
|
|
if (!busiest) {
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(sd->lb_nobusyq[idle]);
|
2009-12-17 16:00:43 +00:00
|
|
|
goto out_balanced;
|
|
|
|
}
|
|
|
|
|
2012-08-06 08:41:59 +00:00
|
|
|
BUG_ON(busiest == env.dst_rq);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_add(sd->lb_imbalance[idle], env.imbalance);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2015-02-27 15:54:14 +00:00
|
|
|
env.src_cpu = busiest->cpu;
|
|
|
|
env.src_rq = busiest;
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
ld_moved = 0;
|
|
|
|
if (busiest->nr_running > 1) {
|
|
|
|
/*
|
|
|
|
* Attempt to move tasks. If find_busiest_group has found
|
|
|
|
* an imbalance but busiest->nr_running <= 1, the group is
|
|
|
|
* still unbalanced. ld_moved simply stays zero, so it is
|
|
|
|
* correctly treated as an imbalance.
|
|
|
|
*/
|
2012-02-22 11:47:19 +00:00
|
|
|
env.flags |= LBF_ALL_PINNED;
|
2012-04-26 11:12:27 +00:00
|
|
|
env.loop_max = min(sysctl_sched_nr_migrate, busiest->nr_running);
|
2012-02-22 11:47:19 +00:00
|
|
|
|
2012-03-09 23:07:36 +00:00
|
|
|
more_balance:
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_lock_irqsave(busiest, &rf);
|
2016-10-03 14:35:32 +00:00
|
|
|
update_rq_clock(busiest);
|
2012-06-19 12:13:15 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* cur_ld_moved - load moved in current iteration
|
|
|
|
* ld_moved - cumulative load moved across iterations
|
|
|
|
*/
|
2014-08-20 09:48:29 +00:00
|
|
|
cur_ld_moved = detach_tasks(&env);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
|
|
|
/*
|
2014-08-20 09:48:29 +00:00
|
|
|
* We've detached some tasks from busiest_rq. Every
|
|
|
|
* task is masked "TASK_ON_RQ_MIGRATING", so we can safely
|
|
|
|
* unlock busiest->lock, and we are able to be sure
|
|
|
|
* that nobody can manipulate the tasks in parallel.
|
|
|
|
* See task_rq_lock() family for the details.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2014-08-20 09:48:29 +00:00
|
|
|
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_unlock(busiest, &rf);
|
2014-08-20 09:48:29 +00:00
|
|
|
|
|
|
|
if (cur_ld_moved) {
|
|
|
|
attach_tasks(&env);
|
|
|
|
ld_moved += cur_ld_moved;
|
|
|
|
}
|
|
|
|
|
2016-10-04 14:04:35 +00:00
|
|
|
local_irq_restore(rf.flags);
|
2012-06-19 12:13:15 +00:00
|
|
|
|
2013-04-23 08:27:37 +00:00
|
|
|
if (env.flags & LBF_NEED_BREAK) {
|
|
|
|
env.flags &= ~LBF_NEED_BREAK;
|
|
|
|
goto more_balance;
|
|
|
|
}
|
|
|
|
|
2012-06-19 12:13:15 +00:00
|
|
|
/*
|
|
|
|
* Revisit (affine) tasks on src_cpu that couldn't be moved to
|
|
|
|
* us and move them to an alternate dst_cpu in our sched_group
|
|
|
|
* where they can run. The upper limit on how many times we
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* iterate on same src_cpu is dependent on number of CPUs in our
|
2012-06-19 12:13:15 +00:00
|
|
|
* sched_group.
|
|
|
|
*
|
|
|
|
* This changes load balance semantics a bit on who can move
|
|
|
|
* load to a given_cpu. In addition to the given_cpu itself
|
|
|
|
* (or a ilb_cpu acting on its behalf where given_cpu is
|
|
|
|
* nohz-idle), we now have balance_cpu in a position to move
|
|
|
|
* load to given_cpu. In rare situations, this may cause
|
|
|
|
* conflicts (balance_cpu and given_cpu/ilb_cpu deciding
|
|
|
|
* _independently_ and at _same_ time to move some load to
|
|
|
|
* given_cpu) causing exceess load to be moved to given_cpu.
|
|
|
|
* This however should not happen so much in practice and
|
|
|
|
* moreover subsequent load balance cycles should correct the
|
|
|
|
* excess load moved.
|
|
|
|
*/
|
2013-08-19 10:41:09 +00:00
|
|
|
if ((env.flags & LBF_DST_PINNED) && env.imbalance > 0) {
|
2012-06-19 12:13:15 +00:00
|
|
|
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/* Prevent to re-select dst_cpu via env's CPUs */
|
2019-02-12 09:27:01 +00:00
|
|
|
__cpumask_clear_cpu(env.dst_cpu, env.cpus);
|
2013-09-15 17:30:13 +00:00
|
|
|
|
2012-08-06 08:41:59 +00:00
|
|
|
env.dst_rq = cpu_rq(env.new_dst_cpu);
|
2012-06-19 12:13:15 +00:00
|
|
|
env.dst_cpu = env.new_dst_cpu;
|
2013-08-19 10:41:09 +00:00
|
|
|
env.flags &= ~LBF_DST_PINNED;
|
2012-06-19 12:13:15 +00:00
|
|
|
env.loop = 0;
|
|
|
|
env.loop_break = sched_nr_migrate_break;
|
2013-04-23 08:27:42 +00:00
|
|
|
|
2012-06-19 12:13:15 +00:00
|
|
|
/*
|
|
|
|
* Go back to "more_balance" rather than "redo" since we
|
|
|
|
* need to continue with same src_cpu.
|
|
|
|
*/
|
|
|
|
goto more_balance;
|
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2013-08-19 10:41:09 +00:00
|
|
|
/*
|
|
|
|
* We failed to reach balance because of affinity.
|
|
|
|
*/
|
|
|
|
if (sd_parent) {
|
2014-05-26 22:19:37 +00:00
|
|
|
int *group_imbalance = &sd_parent->groups->sgc->imbalance;
|
2013-08-19 10:41:09 +00:00
|
|
|
|
2014-08-26 11:06:44 +00:00
|
|
|
if ((env.flags & LBF_SOME_PINNED) && env.imbalance > 0)
|
2013-08-19 10:41:09 +00:00
|
|
|
*group_imbalance = 1;
|
|
|
|
}
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/* All tasks on this runqueue were pinned by CPU affinity */
|
2012-02-22 11:47:19 +00:00
|
|
|
if (unlikely(env.flags & LBF_ALL_PINNED)) {
|
2019-02-12 09:27:01 +00:00
|
|
|
__cpumask_clear_cpu(cpu_of(busiest), cpus);
|
2017-06-07 19:18:57 +00:00
|
|
|
/*
|
|
|
|
* Attempting to continue load balancing at the current
|
|
|
|
* sched_domain level only makes sense if there are
|
|
|
|
* active CPUs remaining as possible busiest CPUs to
|
|
|
|
* pull load from which are not contained within the
|
|
|
|
* destination group that is receiving any migrated
|
|
|
|
* load.
|
|
|
|
*/
|
|
|
|
if (!cpumask_subset(cpus, env.dst_grpmask)) {
|
2012-06-19 12:22:07 +00:00
|
|
|
env.loop = 0;
|
|
|
|
env.loop_break = sched_nr_migrate_break;
|
2009-12-17 16:00:43 +00:00
|
|
|
goto redo;
|
2012-06-19 12:22:07 +00:00
|
|
|
}
|
2014-08-26 11:06:44 +00:00
|
|
|
goto out_all_pinned;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ld_moved) {
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(sd->lb_failed[idle]);
|
2010-09-11 01:19:17 +00:00
|
|
|
/*
|
|
|
|
* Increment the failure counter only on periodic balance.
|
|
|
|
* We do not want newidle balance, which can be very
|
|
|
|
* frequent, pollute the failure counter causing
|
|
|
|
* excessive cache_hot migrations and active balances.
|
|
|
|
*/
|
|
|
|
if (idle != CPU_NEWLY_IDLE)
|
|
|
|
sd->nr_balance_failed++;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2012-05-02 12:20:37 +00:00
|
|
|
if (need_active_balance(&env)) {
|
2016-10-04 14:04:35 +00:00
|
|
|
unsigned long flags;
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
raw_spin_lock_irqsave(&busiest->lock, flags);
|
|
|
|
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/*
|
|
|
|
* Don't kick the active_load_balance_cpu_stop,
|
|
|
|
* if the curr task on busiest CPU can't be
|
|
|
|
* moved to this_cpu:
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2019-04-23 14:26:36 +00:00
|
|
|
if (!cpumask_test_cpu(this_cpu, busiest->curr->cpus_ptr)) {
|
2009-12-17 16:00:43 +00:00
|
|
|
raw_spin_unlock_irqrestore(&busiest->lock,
|
|
|
|
flags);
|
2012-02-22 11:47:19 +00:00
|
|
|
env.flags |= LBF_ALL_PINNED;
|
2009-12-17 16:00:43 +00:00
|
|
|
goto out_one_pinned;
|
|
|
|
}
|
|
|
|
|
2010-05-06 16:49:21 +00:00
|
|
|
/*
|
|
|
|
* ->active_balance synchronizes accesses to
|
|
|
|
* ->active_balance_work. Once set, it's cleared
|
|
|
|
* only after active load balance is finished.
|
|
|
|
*/
|
2009-12-17 16:00:43 +00:00
|
|
|
if (!busiest->active_balance) {
|
|
|
|
busiest->active_balance = 1;
|
|
|
|
busiest->push_cpu = this_cpu;
|
|
|
|
active_balance = 1;
|
|
|
|
}
|
|
|
|
raw_spin_unlock_irqrestore(&busiest->lock, flags);
|
2010-05-06 16:49:21 +00:00
|
|
|
|
2012-05-02 12:20:37 +00:00
|
|
|
if (active_balance) {
|
2010-05-06 16:49:21 +00:00
|
|
|
stop_one_cpu_nowait(cpu_of(busiest),
|
|
|
|
active_load_balance_cpu_stop, busiest,
|
|
|
|
&busiest->active_balance_work);
|
2012-05-02 12:20:37 +00:00
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2016-03-23 12:24:44 +00:00
|
|
|
/* We've kicked active balancing, force task migration. */
|
2009-12-17 16:00:43 +00:00
|
|
|
sd->nr_balance_failed = sd->cache_nice_tries+1;
|
|
|
|
}
|
|
|
|
} else
|
|
|
|
sd->nr_balance_failed = 0;
|
|
|
|
|
2018-12-14 16:01:57 +00:00
|
|
|
if (likely(!active_balance) || voluntary_active_balance(&env)) {
|
2009-12-17 16:00:43 +00:00
|
|
|
/* We were unbalanced, so reset the balancing interval */
|
|
|
|
sd->balance_interval = sd->min_interval;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* If we've begun active balancing, start to back off. This
|
|
|
|
* case may not be covered by the all_pinned logic if there
|
|
|
|
* is only 1 task on the busy runqueue (because we don't call
|
2014-08-20 09:48:29 +00:00
|
|
|
* detach_tasks).
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
|
|
|
if (sd->balance_interval < sd->max_interval)
|
|
|
|
sd->balance_interval *= 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
out_balanced:
|
2014-08-26 11:06:44 +00:00
|
|
|
/*
|
|
|
|
* We reach balance although we may have faced some affinity
|
2019-07-01 15:47:02 +00:00
|
|
|
* constraints. Clear the imbalance flag only if other tasks got
|
|
|
|
* a chance to move and fix the imbalance.
|
2014-08-26 11:06:44 +00:00
|
|
|
*/
|
2019-07-01 15:47:02 +00:00
|
|
|
if (sd_parent && !(env.flags & LBF_ALL_PINNED)) {
|
2014-08-26 11:06:44 +00:00
|
|
|
int *group_imbalance = &sd_parent->groups->sgc->imbalance;
|
|
|
|
|
|
|
|
if (*group_imbalance)
|
|
|
|
*group_imbalance = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
out_all_pinned:
|
|
|
|
/*
|
|
|
|
* We reach balance because all tasks are pinned at this level so
|
|
|
|
* we can't migrate them. Let the imbalance flag set so parent level
|
|
|
|
* can try to migrate them.
|
|
|
|
*/
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(sd->lb_balanced[idle]);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
|
|
|
sd->nr_balance_failed = 0;
|
|
|
|
|
|
|
|
out_one_pinned:
|
2018-09-26 15:12:07 +00:00
|
|
|
ld_moved = 0;
|
|
|
|
|
|
|
|
/*
|
2019-05-29 20:36:42 +00:00
|
|
|
* newidle_balance() disregards balance intervals, so we could
|
|
|
|
* repeatedly reach this code, which would lead to balance_interval
|
|
|
|
* skyrocketting in a short amount of time. Skip the balance_interval
|
|
|
|
* increase logic to avoid that.
|
2018-09-26 15:12:07 +00:00
|
|
|
*/
|
|
|
|
if (env.idle == CPU_NEWLY_IDLE)
|
|
|
|
goto out;
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/* tune up the balancing interval */
|
2018-09-26 15:12:06 +00:00
|
|
|
if ((env.flags & LBF_ALL_PINNED &&
|
|
|
|
sd->balance_interval < MAX_PINNED_INTERVAL) ||
|
|
|
|
sd->balance_interval < sd->max_interval)
|
2009-12-17 16:00:43 +00:00
|
|
|
sd->balance_interval *= 2;
|
|
|
|
out:
|
|
|
|
return ld_moved;
|
|
|
|
}
|
|
|
|
|
sched: Fix the rq->next_balance logic in rebalance_domains() and idle_balance()
Currently, in idle_balance(), we update rq->next_balance when we pull_tasks.
However, it is also important to update this in the !pulled_tasks case too.
When the CPU is "busy" (the CPU isn't idle), rq->next_balance gets computed
using sd->busy_factor (so we increase the balance interval when the CPU is
busy). However, when the CPU goes idle, rq->next_balance could still be set
to a large value that was computed with the sd->busy_factor.
Thus, we need to also update rq->next_balance in idle_balance() in the cases
where !pulled_tasks too, so that rq->next_balance gets updated without taking
the busy_factor into account when the CPU is about to go idle.
This patch makes rq->next_balance get updated independently of whether or
not we pulled_task. Also, we add logic to ensure that we always traverse
at least 1 of the sched domains to get a proper next_balance value for
updating rq->next_balance.
Additionally, since load_balance() modifies the sd->balance_interval, we
need to re-obtain the sched domain's interval after the call to
load_balance() in rebalance_domains() before we update rq->next_balance.
This patch adds and uses 2 new helper functions, update_next_balance() and
get_sd_balance_interval() to update next_balance and obtain the sched
domain's balance_interval.
Signed-off-by: Jason Low <jason.low2@hp.com>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: daniel.lezcano@linaro.org
Cc: alex.shi@linaro.org
Cc: efault@gmx.de
Cc: vincent.guittot@linaro.org
Cc: morten.rasmussen@arm.com
Cc: aswin@hp.com
Link: http://lkml.kernel.org/r/1399596562.2200.7.camel@j-VirtualBox
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-05-09 00:49:22 +00:00
|
|
|
static inline unsigned long
|
|
|
|
get_sd_balance_interval(struct sched_domain *sd, int cpu_busy)
|
|
|
|
{
|
|
|
|
unsigned long interval = sd->balance_interval;
|
|
|
|
|
|
|
|
if (cpu_busy)
|
|
|
|
interval *= sd->busy_factor;
|
|
|
|
|
|
|
|
/* scale ms to jiffies */
|
|
|
|
interval = msecs_to_jiffies(interval);
|
|
|
|
interval = clamp(interval, 1UL, max_load_balance_interval);
|
|
|
|
|
|
|
|
return interval;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
2016-08-05 06:31:29 +00:00
|
|
|
update_next_balance(struct sched_domain *sd, unsigned long *next_balance)
|
sched: Fix the rq->next_balance logic in rebalance_domains() and idle_balance()
Currently, in idle_balance(), we update rq->next_balance when we pull_tasks.
However, it is also important to update this in the !pulled_tasks case too.
When the CPU is "busy" (the CPU isn't idle), rq->next_balance gets computed
using sd->busy_factor (so we increase the balance interval when the CPU is
busy). However, when the CPU goes idle, rq->next_balance could still be set
to a large value that was computed with the sd->busy_factor.
Thus, we need to also update rq->next_balance in idle_balance() in the cases
where !pulled_tasks too, so that rq->next_balance gets updated without taking
the busy_factor into account when the CPU is about to go idle.
This patch makes rq->next_balance get updated independently of whether or
not we pulled_task. Also, we add logic to ensure that we always traverse
at least 1 of the sched domains to get a proper next_balance value for
updating rq->next_balance.
Additionally, since load_balance() modifies the sd->balance_interval, we
need to re-obtain the sched domain's interval after the call to
load_balance() in rebalance_domains() before we update rq->next_balance.
This patch adds and uses 2 new helper functions, update_next_balance() and
get_sd_balance_interval() to update next_balance and obtain the sched
domain's balance_interval.
Signed-off-by: Jason Low <jason.low2@hp.com>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: daniel.lezcano@linaro.org
Cc: alex.shi@linaro.org
Cc: efault@gmx.de
Cc: vincent.guittot@linaro.org
Cc: morten.rasmussen@arm.com
Cc: aswin@hp.com
Link: http://lkml.kernel.org/r/1399596562.2200.7.camel@j-VirtualBox
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-05-09 00:49:22 +00:00
|
|
|
{
|
|
|
|
unsigned long interval, next;
|
|
|
|
|
2016-08-05 06:31:29 +00:00
|
|
|
/* used by idle balance, so cpu_busy = 0 */
|
|
|
|
interval = get_sd_balance_interval(sd, 0);
|
sched: Fix the rq->next_balance logic in rebalance_domains() and idle_balance()
Currently, in idle_balance(), we update rq->next_balance when we pull_tasks.
However, it is also important to update this in the !pulled_tasks case too.
When the CPU is "busy" (the CPU isn't idle), rq->next_balance gets computed
using sd->busy_factor (so we increase the balance interval when the CPU is
busy). However, when the CPU goes idle, rq->next_balance could still be set
to a large value that was computed with the sd->busy_factor.
Thus, we need to also update rq->next_balance in idle_balance() in the cases
where !pulled_tasks too, so that rq->next_balance gets updated without taking
the busy_factor into account when the CPU is about to go idle.
This patch makes rq->next_balance get updated independently of whether or
not we pulled_task. Also, we add logic to ensure that we always traverse
at least 1 of the sched domains to get a proper next_balance value for
updating rq->next_balance.
Additionally, since load_balance() modifies the sd->balance_interval, we
need to re-obtain the sched domain's interval after the call to
load_balance() in rebalance_domains() before we update rq->next_balance.
This patch adds and uses 2 new helper functions, update_next_balance() and
get_sd_balance_interval() to update next_balance and obtain the sched
domain's balance_interval.
Signed-off-by: Jason Low <jason.low2@hp.com>
Reviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: daniel.lezcano@linaro.org
Cc: alex.shi@linaro.org
Cc: efault@gmx.de
Cc: vincent.guittot@linaro.org
Cc: morten.rasmussen@arm.com
Cc: aswin@hp.com
Link: http://lkml.kernel.org/r/1399596562.2200.7.camel@j-VirtualBox
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-05-09 00:49:22 +00:00
|
|
|
next = sd->last_balance + interval;
|
|
|
|
|
|
|
|
if (time_after(*next_balance, next))
|
|
|
|
*next_balance = next;
|
|
|
|
}
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* active_load_balance_cpu_stop is run by the CPU stopper. It pushes
|
2010-05-06 16:49:21 +00:00
|
|
|
* running tasks off the busiest CPU onto idle CPUs. It requires at
|
|
|
|
* least 1 task to be running on each physical CPU where possible, and
|
|
|
|
* avoids physical / logical imbalances.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2010-05-06 16:49:21 +00:00
|
|
|
static int active_load_balance_cpu_stop(void *data)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2010-05-06 16:49:21 +00:00
|
|
|
struct rq *busiest_rq = data;
|
|
|
|
int busiest_cpu = cpu_of(busiest_rq);
|
2009-12-17 16:00:43 +00:00
|
|
|
int target_cpu = busiest_rq->push_cpu;
|
2010-05-06 16:49:21 +00:00
|
|
|
struct rq *target_rq = cpu_rq(target_cpu);
|
2009-12-17 16:00:43 +00:00
|
|
|
struct sched_domain *sd;
|
2014-08-20 09:48:01 +00:00
|
|
|
struct task_struct *p = NULL;
|
2016-10-04 14:04:35 +00:00
|
|
|
struct rq_flags rf;
|
2010-05-06 16:49:21 +00:00
|
|
|
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_lock_irq(busiest_rq, &rf);
|
2017-09-07 15:03:51 +00:00
|
|
|
/*
|
|
|
|
* Between queueing the stop-work and running it is a hole in which
|
|
|
|
* CPUs can become inactive. We should not move tasks from or to
|
|
|
|
* inactive CPUs.
|
|
|
|
*/
|
|
|
|
if (!cpu_active(busiest_cpu) || !cpu_active(target_cpu))
|
|
|
|
goto out_unlock;
|
2010-05-06 16:49:21 +00:00
|
|
|
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/* Make sure the requested CPU hasn't gone down in the meantime: */
|
2010-05-06 16:49:21 +00:00
|
|
|
if (unlikely(busiest_cpu != smp_processor_id() ||
|
|
|
|
!busiest_rq->active_balance))
|
|
|
|
goto out_unlock;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
|
|
|
/* Is there any task to move? */
|
|
|
|
if (busiest_rq->nr_running <= 1)
|
2010-05-06 16:49:21 +00:00
|
|
|
goto out_unlock;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This condition is "impossible", if it occurs
|
|
|
|
* we need to fix it. Originally reported by
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* Bjorn Helgaas on a 128-CPU setup.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
|
|
|
BUG_ON(busiest_rq == target_rq);
|
|
|
|
|
|
|
|
/* Search for an sd spanning us and the target CPU. */
|
2011-04-07 12:09:50 +00:00
|
|
|
rcu_read_lock();
|
2009-12-17 16:00:43 +00:00
|
|
|
for_each_domain(target_cpu, sd) {
|
|
|
|
if ((sd->flags & SD_LOAD_BALANCE) &&
|
|
|
|
cpumask_test_cpu(busiest_cpu, sched_domain_span(sd)))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (likely(sd)) {
|
2012-02-22 11:47:19 +00:00
|
|
|
struct lb_env env = {
|
|
|
|
.sd = sd,
|
2012-02-22 18:27:40 +00:00
|
|
|
.dst_cpu = target_cpu,
|
|
|
|
.dst_rq = target_rq,
|
|
|
|
.src_cpu = busiest_rq->cpu,
|
|
|
|
.src_rq = busiest_rq,
|
2012-02-22 11:47:19 +00:00
|
|
|
.idle = CPU_IDLE,
|
2017-06-07 19:18:57 +00:00
|
|
|
/*
|
|
|
|
* can_migrate_task() doesn't need to compute new_dst_cpu
|
|
|
|
* for active balancing. Since we have CPU_IDLE, but no
|
|
|
|
* @dst_grpmask we need to make that test go away with lying
|
|
|
|
* about DST_PINNED.
|
|
|
|
*/
|
|
|
|
.flags = LBF_DST_PINNED,
|
2012-02-22 11:47:19 +00:00
|
|
|
};
|
|
|
|
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(sd->alb_count);
|
2016-10-03 14:35:32 +00:00
|
|
|
update_rq_clock(busiest_rq);
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2014-08-20 09:48:01 +00:00
|
|
|
p = detach_one_task(&env);
|
2016-03-23 12:24:44 +00:00
|
|
|
if (p) {
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(sd->alb_pushed);
|
2016-03-23 12:24:44 +00:00
|
|
|
/* Active balancing done, reset the failure counter. */
|
|
|
|
sd->nr_balance_failed = 0;
|
|
|
|
} else {
|
2016-06-17 17:43:24 +00:00
|
|
|
schedstat_inc(sd->alb_failed);
|
2016-03-23 12:24:44 +00:00
|
|
|
}
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
2011-04-07 12:09:50 +00:00
|
|
|
rcu_read_unlock();
|
2010-05-06 16:49:21 +00:00
|
|
|
out_unlock:
|
|
|
|
busiest_rq->active_balance = 0;
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_unlock(busiest_rq, &rf);
|
2014-08-20 09:48:01 +00:00
|
|
|
|
|
|
|
if (p)
|
|
|
|
attach_one_task(target_rq, p);
|
|
|
|
|
|
|
|
local_irq_enable();
|
|
|
|
|
2010-05-06 16:49:21 +00:00
|
|
|
return 0;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2018-02-20 09:58:39 +00:00
|
|
|
static DEFINE_SPINLOCK(balancing);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Scale the max load_balance interval with the number of CPUs in the system.
|
|
|
|
* This trades load-balance latency on larger machines for less cross talk.
|
|
|
|
*/
|
|
|
|
void update_max_interval(void)
|
|
|
|
{
|
|
|
|
max_load_balance_interval = HZ*num_online_cpus()/10;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It checks each scheduling domain to see if it is due to be balanced,
|
|
|
|
* and initiates a balancing operation if so.
|
|
|
|
*
|
|
|
|
* Balancing parameters are set up in init_sched_domains.
|
|
|
|
*/
|
|
|
|
static void rebalance_domains(struct rq *rq, enum cpu_idle_type idle)
|
|
|
|
{
|
|
|
|
int continue_balancing = 1;
|
|
|
|
int cpu = rq->cpu;
|
2020-01-08 08:27:04 +00:00
|
|
|
int busy = idle != CPU_IDLE && !sched_idle_cpu(cpu);
|
2018-02-20 09:58:39 +00:00
|
|
|
unsigned long interval;
|
|
|
|
struct sched_domain *sd;
|
|
|
|
/* Earliest time when we have to do rebalance again */
|
|
|
|
unsigned long next_balance = jiffies + 60*HZ;
|
|
|
|
int update_next_balance = 0;
|
|
|
|
int need_serialize, need_decay = 0;
|
|
|
|
u64 max_cost = 0;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
for_each_domain(cpu, sd) {
|
|
|
|
/*
|
|
|
|
* Decay the newidle max times here because this is a regular
|
|
|
|
* visit to all the domains. Decay ~1% per second.
|
|
|
|
*/
|
|
|
|
if (time_after(jiffies, sd->next_decay_max_lb_cost)) {
|
|
|
|
sd->max_newidle_lb_cost =
|
|
|
|
(sd->max_newidle_lb_cost * 253) / 256;
|
|
|
|
sd->next_decay_max_lb_cost = jiffies + HZ;
|
|
|
|
need_decay = 1;
|
|
|
|
}
|
|
|
|
max_cost += sd->max_newidle_lb_cost;
|
|
|
|
|
|
|
|
if (!(sd->flags & SD_LOAD_BALANCE))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Stop the load balance at this level. There is another
|
|
|
|
* CPU in our sched group which is doing load balancing more
|
|
|
|
* actively.
|
|
|
|
*/
|
|
|
|
if (!continue_balancing) {
|
|
|
|
if (need_decay)
|
|
|
|
continue;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2020-01-08 08:27:04 +00:00
|
|
|
interval = get_sd_balance_interval(sd, busy);
|
2018-02-20 09:58:39 +00:00
|
|
|
|
|
|
|
need_serialize = sd->flags & SD_SERIALIZE;
|
|
|
|
if (need_serialize) {
|
|
|
|
if (!spin_trylock(&balancing))
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (time_after_eq(jiffies, sd->last_balance + interval)) {
|
|
|
|
if (load_balance(cpu, rq, sd, idle, &continue_balancing)) {
|
|
|
|
/*
|
|
|
|
* The LBF_DST_PINNED logic could have changed
|
|
|
|
* env->dst_cpu, so we can't know our idle
|
|
|
|
* state even if we migrated tasks. Update it.
|
|
|
|
*/
|
|
|
|
idle = idle_cpu(cpu) ? CPU_IDLE : CPU_NOT_IDLE;
|
2020-01-08 08:27:04 +00:00
|
|
|
busy = idle != CPU_IDLE && !sched_idle_cpu(cpu);
|
2018-02-20 09:58:39 +00:00
|
|
|
}
|
|
|
|
sd->last_balance = jiffies;
|
2020-01-08 08:27:04 +00:00
|
|
|
interval = get_sd_balance_interval(sd, busy);
|
2018-02-20 09:58:39 +00:00
|
|
|
}
|
|
|
|
if (need_serialize)
|
|
|
|
spin_unlock(&balancing);
|
|
|
|
out:
|
|
|
|
if (time_after(next_balance, sd->last_balance + interval)) {
|
|
|
|
next_balance = sd->last_balance + interval;
|
|
|
|
update_next_balance = 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (need_decay) {
|
|
|
|
/*
|
|
|
|
* Ensure the rq-wide value also decays but keep it at a
|
|
|
|
* reasonable floor to avoid funnies with rq->avg_idle.
|
|
|
|
*/
|
|
|
|
rq->max_idle_balance_cost =
|
|
|
|
max((u64)sysctl_sched_migration_cost, max_cost);
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* next_balance will be updated only when there is a need.
|
|
|
|
* When the cpu is attached to null domain for ex, it will not be
|
|
|
|
* updated.
|
|
|
|
*/
|
|
|
|
if (likely(update_next_balance)) {
|
|
|
|
rq->next_balance = next_balance;
|
|
|
|
|
|
|
|
#ifdef CONFIG_NO_HZ_COMMON
|
|
|
|
/*
|
|
|
|
* If this CPU has been elected to perform the nohz idle
|
|
|
|
* balance. Other idle CPUs have already rebalanced with
|
|
|
|
* nohz_idle_balance() and nohz.next_balance has been
|
|
|
|
* updated accordingly. This CPU is now running the idle load
|
|
|
|
* balance for itself and we need to update the
|
|
|
|
* nohz.next_balance accordingly.
|
|
|
|
*/
|
|
|
|
if ((idle == CPU_IDLE) && time_after(nohz.next_balance, rq->next_balance))
|
|
|
|
nohz.next_balance = rq->next_balance;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-05 09:01:47 +00:00
|
|
|
static inline int on_null_domain(struct rq *rq)
|
|
|
|
{
|
|
|
|
return unlikely(!rcu_dereference_sched(rq->sd));
|
|
|
|
}
|
|
|
|
|
2011-08-10 21:21:01 +00:00
|
|
|
#ifdef CONFIG_NO_HZ_COMMON
|
2010-05-22 00:09:41 +00:00
|
|
|
/*
|
|
|
|
* idle load balancing details
|
|
|
|
* - When one of the busy CPUs notice that there may be an idle rebalancing
|
|
|
|
* needed, they will kick the idle load balancer, which then does idle
|
|
|
|
* load balancing for all the idle CPUs.
|
2019-04-12 04:26:13 +00:00
|
|
|
* - HK_FLAG_MISC CPUs are used for this task, because HK_FLAG_SCHED not set
|
|
|
|
* anywhere yet.
|
2010-05-22 00:09:41 +00:00
|
|
|
*/
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2014-01-06 11:34:41 +00:00
|
|
|
static inline int find_new_ilb(void)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2019-04-12 04:26:13 +00:00
|
|
|
int ilb;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
2019-04-12 04:26:13 +00:00
|
|
|
for_each_cpu_and(ilb, nohz.idle_cpus_mask,
|
|
|
|
housekeeping_cpumask(HK_FLAG_MISC)) {
|
|
|
|
if (idle_cpu(ilb))
|
|
|
|
return ilb;
|
|
|
|
}
|
2011-12-02 01:07:35 +00:00
|
|
|
|
|
|
|
return nr_cpu_ids;
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2010-05-22 00:09:41 +00:00
|
|
|
/*
|
2019-04-12 04:26:13 +00:00
|
|
|
* Kick a CPU to do the nohz balancing, if it is time for it. We pick any
|
|
|
|
* idle CPU in the HK_FLAG_MISC housekeeping set (if there is one).
|
2010-05-22 00:09:41 +00:00
|
|
|
*/
|
2017-12-21 09:42:50 +00:00
|
|
|
static void kick_ilb(unsigned int flags)
|
2010-05-22 00:09:41 +00:00
|
|
|
{
|
|
|
|
int ilb_cpu;
|
|
|
|
|
|
|
|
nohz.next_balance++;
|
|
|
|
|
2014-01-06 11:34:41 +00:00
|
|
|
ilb_cpu = find_new_ilb();
|
2010-05-22 00:09:41 +00:00
|
|
|
|
2011-12-02 01:07:34 +00:00
|
|
|
if (ilb_cpu >= nr_cpu_ids)
|
|
|
|
return;
|
2010-05-22 00:09:41 +00:00
|
|
|
|
2017-12-21 09:42:50 +00:00
|
|
|
flags = atomic_fetch_or(flags, nohz_flags(ilb_cpu));
|
2017-12-21 09:11:09 +00:00
|
|
|
if (flags & NOHZ_KICK_MASK)
|
2011-12-02 01:07:32 +00:00
|
|
|
return;
|
2017-12-21 09:47:48 +00:00
|
|
|
|
2011-12-02 01:07:32 +00:00
|
|
|
/*
|
|
|
|
* Use smp_send_reschedule() instead of resched_cpu().
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* This way we generate a sched IPI on the target CPU which
|
2011-12-02 01:07:32 +00:00
|
|
|
* is idle. And the softirq performing nohz idle load balance
|
|
|
|
* will be run before returning from the IPI.
|
|
|
|
*/
|
|
|
|
smp_send_reschedule(ilb_cpu);
|
2017-12-21 09:47:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2019-01-17 15:34:09 +00:00
|
|
|
* Current decision point for kicking the idle load balancer in the presence
|
|
|
|
* of idle CPUs in the system.
|
2017-12-21 09:47:48 +00:00
|
|
|
*/
|
|
|
|
static void nohz_balancer_kick(struct rq *rq)
|
|
|
|
{
|
|
|
|
unsigned long now = jiffies;
|
|
|
|
struct sched_domain_shared *sds;
|
|
|
|
struct sched_domain *sd;
|
|
|
|
int nr_busy, i, cpu = rq->cpu;
|
2017-12-21 09:42:50 +00:00
|
|
|
unsigned int flags = 0;
|
2017-12-21 09:47:48 +00:00
|
|
|
|
|
|
|
if (unlikely(rq->idle_balance))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We may be recently in ticked or tickless idle mode. At the first
|
|
|
|
* busy tick after returning from idle, we will update the busy stats.
|
|
|
|
*/
|
2017-12-21 14:06:50 +00:00
|
|
|
nohz_balance_exit_idle(rq);
|
2017-12-21 09:47:48 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* None are in tickless mode and hence no need for NOHZ idle load
|
|
|
|
* balancing.
|
|
|
|
*/
|
|
|
|
if (likely(!atomic_read(&nohz.nr_cpus)))
|
|
|
|
return;
|
|
|
|
|
2018-02-13 10:31:17 +00:00
|
|
|
if (READ_ONCE(nohz.has_blocked) &&
|
|
|
|
time_after(now, READ_ONCE(nohz.next_blocked)))
|
2017-12-21 09:42:50 +00:00
|
|
|
flags = NOHZ_STATS_KICK;
|
|
|
|
|
2017-12-21 09:47:48 +00:00
|
|
|
if (time_before(now, nohz.next_balance))
|
2017-12-21 09:42:50 +00:00
|
|
|
goto out;
|
2017-12-21 09:47:48 +00:00
|
|
|
|
2019-02-11 17:59:45 +00:00
|
|
|
if (rq->nr_running >= 2) {
|
2017-12-21 09:42:50 +00:00
|
|
|
flags = NOHZ_KICK_MASK;
|
2017-12-21 09:47:48 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
|
|
|
|
sd = rcu_dereference(rq->sd);
|
|
|
|
if (sd) {
|
2019-02-11 17:59:44 +00:00
|
|
|
/*
|
|
|
|
* If there's a CFS task and the current CPU has reduced
|
|
|
|
* capacity; kick the ILB to see if there's a better CPU to run
|
|
|
|
* on.
|
|
|
|
*/
|
|
|
|
if (rq->cfs.h_nr_running >= 1 && check_cpu_capacity(rq, sd)) {
|
2017-12-21 09:42:50 +00:00
|
|
|
flags = NOHZ_KICK_MASK;
|
2017-12-21 09:47:48 +00:00
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-03 09:56:19 +00:00
|
|
|
sd = rcu_dereference(per_cpu(sd_asym_packing, cpu));
|
2017-12-21 09:47:48 +00:00
|
|
|
if (sd) {
|
2019-02-11 17:59:46 +00:00
|
|
|
/*
|
|
|
|
* When ASYM_PACKING; see if there's a more preferred CPU
|
|
|
|
* currently idle; in which case, kick the ILB to move tasks
|
|
|
|
* around.
|
|
|
|
*/
|
2019-01-17 15:34:07 +00:00
|
|
|
for_each_cpu_and(i, sched_domain_span(sd), nohz.idle_cpus_mask) {
|
2017-12-21 09:47:48 +00:00
|
|
|
if (sched_asym_prefer(i, cpu)) {
|
2017-12-21 09:42:50 +00:00
|
|
|
flags = NOHZ_KICK_MASK;
|
2017-12-21 09:47:48 +00:00
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-02-11 17:59:46 +00:00
|
|
|
|
2019-02-11 17:59:45 +00:00
|
|
|
sd = rcu_dereference(per_cpu(sd_asym_cpucapacity, cpu));
|
|
|
|
if (sd) {
|
|
|
|
/*
|
|
|
|
* When ASYM_CPUCAPACITY; see if there's a higher capacity CPU
|
|
|
|
* to run the misfit task on.
|
|
|
|
*/
|
|
|
|
if (check_misfit_status(rq, sd)) {
|
|
|
|
flags = NOHZ_KICK_MASK;
|
|
|
|
goto unlock;
|
|
|
|
}
|
2019-02-11 17:59:46 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For asymmetric systems, we do not want to nicely balance
|
|
|
|
* cache use, instead we want to embrace asymmetry and only
|
|
|
|
* ensure tasks have enough CPU capacity.
|
|
|
|
*
|
|
|
|
* Skip the LLC logic because it's not relevant in that case.
|
|
|
|
*/
|
|
|
|
goto unlock;
|
2019-02-11 17:59:45 +00:00
|
|
|
}
|
|
|
|
|
2019-02-11 17:59:46 +00:00
|
|
|
sds = rcu_dereference(per_cpu(sd_llc_shared, cpu));
|
|
|
|
if (sds) {
|
2019-02-11 17:59:44 +00:00
|
|
|
/*
|
2019-02-11 17:59:46 +00:00
|
|
|
* If there is an imbalance between LLC domains (IOW we could
|
|
|
|
* increase the overall cache use), we need some less-loaded LLC
|
|
|
|
* domain to pull some load. Likewise, we may need to spread
|
|
|
|
* load within the current LLC domain (e.g. packed SMT cores but
|
|
|
|
* other CPUs are idle). We can't really know from here how busy
|
|
|
|
* the others are - so just get a nohz balance going if it looks
|
|
|
|
* like this LLC domain has tasks we could move.
|
2019-02-11 17:59:44 +00:00
|
|
|
*/
|
2019-02-11 17:59:46 +00:00
|
|
|
nr_busy = atomic_read(&sds->nr_busy_cpus);
|
|
|
|
if (nr_busy > 1) {
|
|
|
|
flags = NOHZ_KICK_MASK;
|
|
|
|
goto unlock;
|
2017-12-21 09:47:48 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
unlock:
|
|
|
|
rcu_read_unlock();
|
|
|
|
out:
|
2017-12-21 09:42:50 +00:00
|
|
|
if (flags)
|
|
|
|
kick_ilb(flags);
|
2010-05-22 00:09:41 +00:00
|
|
|
}
|
|
|
|
|
2017-12-21 14:06:50 +00:00
|
|
|
static void set_cpu_sd_state_busy(int cpu)
|
2012-01-20 02:28:57 +00:00
|
|
|
{
|
2017-12-21 14:06:50 +00:00
|
|
|
struct sched_domain *sd;
|
2017-12-21 09:01:24 +00:00
|
|
|
|
2017-12-21 14:06:50 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
sd = rcu_dereference(per_cpu(sd_llc, cpu));
|
2017-12-21 09:01:24 +00:00
|
|
|
|
2017-12-21 14:06:50 +00:00
|
|
|
if (!sd || !sd->nohz_idle)
|
|
|
|
goto unlock;
|
|
|
|
sd->nohz_idle = 0;
|
|
|
|
|
|
|
|
atomic_inc(&sd->shared->nr_busy_cpus);
|
|
|
|
unlock:
|
|
|
|
rcu_read_unlock();
|
2012-01-20 02:28:57 +00:00
|
|
|
}
|
|
|
|
|
2017-12-21 14:06:50 +00:00
|
|
|
void nohz_balance_exit_idle(struct rq *rq)
|
|
|
|
{
|
|
|
|
SCHED_WARN_ON(rq != this_rq());
|
|
|
|
|
|
|
|
if (likely(!rq->nohz_tick_stopped))
|
|
|
|
return;
|
|
|
|
|
|
|
|
rq->nohz_tick_stopped = 0;
|
|
|
|
cpumask_clear_cpu(rq->cpu, nohz.idle_cpus_mask);
|
|
|
|
atomic_dec(&nohz.nr_cpus);
|
|
|
|
|
|
|
|
set_cpu_sd_state_busy(rq->cpu);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_cpu_sd_state_idle(int cpu)
|
2011-12-02 01:07:33 +00:00
|
|
|
{
|
|
|
|
struct sched_domain *sd;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
2016-05-09 08:38:01 +00:00
|
|
|
sd = rcu_dereference(per_cpu(sd_llc, cpu));
|
2013-04-23 14:59:02 +00:00
|
|
|
|
|
|
|
if (!sd || sd->nohz_idle)
|
|
|
|
goto unlock;
|
|
|
|
sd->nohz_idle = 1;
|
|
|
|
|
2016-05-09 08:38:01 +00:00
|
|
|
atomic_dec(&sd->shared->nr_busy_cpus);
|
2013-04-23 14:59:02 +00:00
|
|
|
unlock:
|
2011-12-02 01:07:33 +00:00
|
|
|
rcu_read_unlock();
|
|
|
|
}
|
|
|
|
|
2009-12-17 16:00:43 +00:00
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* This routine will record that the CPU is going idle with tick stopped.
|
2011-12-02 01:07:34 +00:00
|
|
|
* This info will be used in performing idle load balancing in the future.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2012-09-10 07:10:58 +00:00
|
|
|
void nohz_balance_enter_idle(int cpu)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2017-12-21 14:06:50 +00:00
|
|
|
struct rq *rq = cpu_rq(cpu);
|
|
|
|
|
|
|
|
SCHED_WARN_ON(cpu != smp_processor_id());
|
|
|
|
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/* If this CPU is going down, then nothing needs to be done: */
|
2012-01-20 02:28:57 +00:00
|
|
|
if (!cpu_active(cpu))
|
|
|
|
return;
|
|
|
|
|
2017-06-19 02:12:02 +00:00
|
|
|
/* Spare idle load balancing on CPUs that don't want to be disturbed: */
|
2017-10-27 02:42:35 +00:00
|
|
|
if (!housekeeping_cpu(cpu, HK_FLAG_SCHED))
|
2017-06-19 02:12:02 +00:00
|
|
|
return;
|
|
|
|
|
2018-02-13 10:31:17 +00:00
|
|
|
/*
|
|
|
|
* Can be set safely without rq->lock held
|
|
|
|
* If a clear happens, it will have evaluated last additions because
|
|
|
|
* rq->lock is held during the check and the clear
|
|
|
|
*/
|
|
|
|
rq->has_blocked_load = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The tick is still stopped but load could have been added in the
|
|
|
|
* meantime. We set the nohz.has_blocked flag to trig a check of the
|
|
|
|
* *_avg. The CPU is already part of nohz.idle_cpus_mask so the clear
|
|
|
|
* of nohz.has_blocked can only happen after checking the new load
|
|
|
|
*/
|
2017-12-21 14:06:50 +00:00
|
|
|
if (rq->nohz_tick_stopped)
|
2018-02-13 10:31:17 +00:00
|
|
|
goto out;
|
2009-12-17 16:00:43 +00:00
|
|
|
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
/* If we're a completely isolated CPU, we don't play: */
|
2017-12-21 14:06:50 +00:00
|
|
|
if (on_null_domain(rq))
|
2011-12-05 09:01:47 +00:00
|
|
|
return;
|
|
|
|
|
2017-12-21 14:06:50 +00:00
|
|
|
rq->nohz_tick_stopped = 1;
|
|
|
|
|
2012-09-10 07:10:58 +00:00
|
|
|
cpumask_set_cpu(cpu, nohz.idle_cpus_mask);
|
|
|
|
atomic_inc(&nohz.nr_cpus);
|
2017-12-21 14:06:50 +00:00
|
|
|
|
2018-02-13 10:31:17 +00:00
|
|
|
/*
|
|
|
|
* Ensures that if nohz_idle_balance() fails to observe our
|
|
|
|
* @idle_cpus_mask store, it must observe the @has_blocked
|
|
|
|
* store.
|
|
|
|
*/
|
|
|
|
smp_mb__after_atomic();
|
|
|
|
|
2017-12-21 14:06:50 +00:00
|
|
|
set_cpu_sd_state_idle(cpu);
|
2018-02-13 10:31:17 +00:00
|
|
|
|
|
|
|
out:
|
|
|
|
/*
|
|
|
|
* Each time a cpu enter idle, we assume that it has blocked load and
|
|
|
|
* enable the periodic update of the load of idle cpus
|
|
|
|
*/
|
|
|
|
WRITE_ONCE(nohz.has_blocked, 1);
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2018-02-14 15:26:46 +00:00
|
|
|
* Internal function that runs load balance for all idle cpus. The load balance
|
|
|
|
* can be a simple update of blocked load or a complete load balance with
|
|
|
|
* tasks movement depending of flags.
|
|
|
|
* The function returns false if the loop has stopped before running
|
|
|
|
* through all idle CPUs.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2018-02-14 15:26:46 +00:00
|
|
|
static bool _nohz_idle_balance(struct rq *this_rq, unsigned int flags,
|
|
|
|
enum cpu_idle_type idle)
|
2010-05-22 00:09:41 +00:00
|
|
|
{
|
2015-08-03 09:55:50 +00:00
|
|
|
/* Earliest time when we have to do rebalance again */
|
2017-12-21 09:42:50 +00:00
|
|
|
unsigned long now = jiffies;
|
|
|
|
unsigned long next_balance = now + 60*HZ;
|
2018-02-13 10:31:17 +00:00
|
|
|
bool has_blocked_load = false;
|
2015-08-03 09:55:50 +00:00
|
|
|
int update_next_balance = 0;
|
2017-12-21 09:11:09 +00:00
|
|
|
int this_cpu = this_rq->cpu;
|
|
|
|
int balance_cpu;
|
2018-02-14 15:26:46 +00:00
|
|
|
int ret = false;
|
2017-12-21 09:11:09 +00:00
|
|
|
struct rq *rq;
|
2010-05-22 00:09:41 +00:00
|
|
|
|
2017-12-21 09:11:09 +00:00
|
|
|
SCHED_WARN_ON((flags & NOHZ_KICK_MASK) == NOHZ_BALANCE_KICK);
|
2010-05-22 00:09:41 +00:00
|
|
|
|
2018-02-13 10:31:17 +00:00
|
|
|
/*
|
|
|
|
* We assume there will be no idle load after this update and clear
|
|
|
|
* the has_blocked flag. If a cpu enters idle in the mean time, it will
|
|
|
|
* set the has_blocked flag and trig another update of idle load.
|
|
|
|
* Because a cpu that becomes idle, is added to idle_cpus_mask before
|
|
|
|
* setting the flag, we are sure to not clear the state and not
|
|
|
|
* check the load of an idle cpu.
|
|
|
|
*/
|
|
|
|
WRITE_ONCE(nohz.has_blocked, 0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensures that if we miss the CPU, we must see the has_blocked
|
|
|
|
* store from nohz_balance_enter_idle().
|
|
|
|
*/
|
|
|
|
smp_mb();
|
|
|
|
|
2010-05-22 00:09:41 +00:00
|
|
|
for_each_cpu(balance_cpu, nohz.idle_cpus_mask) {
|
2011-12-06 19:19:37 +00:00
|
|
|
if (balance_cpu == this_cpu || !idle_cpu(balance_cpu))
|
2010-05-22 00:09:41 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* If this CPU gets work to do, stop the load balancing
|
|
|
|
* work being done for other CPUs. Next load
|
2010-05-22 00:09:41 +00:00
|
|
|
* balancing owner will pick it up.
|
|
|
|
*/
|
2018-02-13 10:31:17 +00:00
|
|
|
if (need_resched()) {
|
|
|
|
has_blocked_load = true;
|
|
|
|
goto abort;
|
|
|
|
}
|
2010-05-22 00:09:41 +00:00
|
|
|
|
2012-09-13 04:11:26 +00:00
|
|
|
rq = cpu_rq(balance_cpu);
|
|
|
|
|
2018-02-13 15:54:17 +00:00
|
|
|
has_blocked_load |= update_nohz_stats(rq, true);
|
2018-02-13 10:31:17 +00:00
|
|
|
|
2014-05-20 21:39:27 +00:00
|
|
|
/*
|
|
|
|
* If time for next balance is due,
|
|
|
|
* do the balance.
|
|
|
|
*/
|
|
|
|
if (time_after_eq(jiffies, rq->next_balance)) {
|
2016-10-04 14:04:35 +00:00
|
|
|
struct rq_flags rf;
|
|
|
|
|
2018-02-14 15:26:46 +00:00
|
|
|
rq_lock_irqsave(rq, &rf);
|
2014-05-20 21:39:27 +00:00
|
|
|
update_rq_clock(rq);
|
2018-02-14 15:26:46 +00:00
|
|
|
rq_unlock_irqrestore(rq, &rf);
|
2016-10-04 14:04:35 +00:00
|
|
|
|
2017-12-21 09:11:09 +00:00
|
|
|
if (flags & NOHZ_BALANCE_KICK)
|
|
|
|
rebalance_domains(rq, CPU_IDLE);
|
2014-05-20 21:39:27 +00:00
|
|
|
}
|
2010-05-22 00:09:41 +00:00
|
|
|
|
2015-08-03 09:55:50 +00:00
|
|
|
if (time_after(next_balance, rq->next_balance)) {
|
|
|
|
next_balance = rq->next_balance;
|
|
|
|
update_next_balance = 1;
|
|
|
|
}
|
2010-05-22 00:09:41 +00:00
|
|
|
}
|
2015-08-03 09:55:50 +00:00
|
|
|
|
2018-02-14 15:26:46 +00:00
|
|
|
/* Newly idle CPU doesn't need an update */
|
|
|
|
if (idle != CPU_NEWLY_IDLE) {
|
|
|
|
update_blocked_averages(this_cpu);
|
|
|
|
has_blocked_load |= this_rq->has_blocked_load;
|
|
|
|
}
|
|
|
|
|
2017-12-21 09:11:09 +00:00
|
|
|
if (flags & NOHZ_BALANCE_KICK)
|
|
|
|
rebalance_domains(this_rq, CPU_IDLE);
|
|
|
|
|
2018-02-13 10:31:17 +00:00
|
|
|
WRITE_ONCE(nohz.next_blocked,
|
|
|
|
now + msecs_to_jiffies(LOAD_AVG_PERIOD));
|
|
|
|
|
2018-02-14 15:26:46 +00:00
|
|
|
/* The full idle balance loop has been done */
|
|
|
|
ret = true;
|
|
|
|
|
2018-02-13 10:31:17 +00:00
|
|
|
abort:
|
|
|
|
/* There is still blocked load, enable periodic update */
|
|
|
|
if (has_blocked_load)
|
|
|
|
WRITE_ONCE(nohz.has_blocked, 1);
|
2017-12-21 09:42:50 +00:00
|
|
|
|
2015-08-03 09:55:50 +00:00
|
|
|
/*
|
|
|
|
* next_balance will be updated only when there is a need.
|
|
|
|
* When the CPU is attached to null domain for ex, it will not be
|
|
|
|
* updated.
|
|
|
|
*/
|
|
|
|
if (likely(update_next_balance))
|
|
|
|
nohz.next_balance = next_balance;
|
2017-12-21 09:11:09 +00:00
|
|
|
|
2018-02-14 15:26:46 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* In CONFIG_NO_HZ_COMMON case, the idle balance kickee will do the
|
|
|
|
* rebalancing for all the cpus for whom scheduler ticks are stopped.
|
|
|
|
*/
|
|
|
|
static bool nohz_idle_balance(struct rq *this_rq, enum cpu_idle_type idle)
|
|
|
|
{
|
|
|
|
int this_cpu = this_rq->cpu;
|
|
|
|
unsigned int flags;
|
|
|
|
|
|
|
|
if (!(atomic_read(nohz_flags(this_cpu)) & NOHZ_KICK_MASK))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (idle != CPU_IDLE) {
|
|
|
|
atomic_andnot(NOHZ_KICK_MASK, nohz_flags(this_cpu));
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-11-27 11:01:10 +00:00
|
|
|
/* could be _relaxed() */
|
2018-02-14 15:26:46 +00:00
|
|
|
flags = atomic_fetch_andnot(NOHZ_KICK_MASK, nohz_flags(this_cpu));
|
|
|
|
if (!(flags & NOHZ_KICK_MASK))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
_nohz_idle_balance(this_rq, flags, idle);
|
|
|
|
|
2017-12-21 09:11:09 +00:00
|
|
|
return true;
|
2010-05-22 00:09:41 +00:00
|
|
|
}
|
2018-02-14 15:26:46 +00:00
|
|
|
|
|
|
|
static void nohz_newidle_balance(struct rq *this_rq)
|
|
|
|
{
|
|
|
|
int this_cpu = this_rq->cpu;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This CPU doesn't want to be disturbed by scheduler
|
|
|
|
* housekeeping
|
|
|
|
*/
|
|
|
|
if (!housekeeping_cpu(this_cpu, HK_FLAG_SCHED))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Will wake up very soon. No time for doing anything else*/
|
|
|
|
if (this_rq->avg_idle < sysctl_sched_migration_cost)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Don't need to update blocked load of idle CPUs*/
|
|
|
|
if (!READ_ONCE(nohz.has_blocked) ||
|
|
|
|
time_before(jiffies, READ_ONCE(nohz.next_blocked)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
raw_spin_unlock(&this_rq->lock);
|
|
|
|
/*
|
|
|
|
* This CPU is going to be idle and blocked load of idle CPUs
|
|
|
|
* need to be updated. Run the ilb locally as it is a good
|
|
|
|
* candidate for ilb instead of waking up another idle CPU.
|
|
|
|
* Kick an normal ilb if we failed to do the update.
|
|
|
|
*/
|
|
|
|
if (!_nohz_idle_balance(this_rq, NOHZ_STATS_KICK, CPU_NEWLY_IDLE))
|
|
|
|
kick_ilb(NOHZ_STATS_KICK);
|
|
|
|
raw_spin_lock(&this_rq->lock);
|
|
|
|
}
|
|
|
|
|
2018-02-20 09:59:45 +00:00
|
|
|
#else /* !CONFIG_NO_HZ_COMMON */
|
|
|
|
static inline void nohz_balancer_kick(struct rq *rq) { }
|
|
|
|
|
2018-02-14 15:26:46 +00:00
|
|
|
static inline bool nohz_idle_balance(struct rq *this_rq, enum cpu_idle_type idle)
|
2017-12-21 09:11:09 +00:00
|
|
|
{
|
|
|
|
return false;
|
|
|
|
}
|
2018-02-14 15:26:46 +00:00
|
|
|
|
|
|
|
static inline void nohz_newidle_balance(struct rq *this_rq) { }
|
2018-02-20 09:59:45 +00:00
|
|
|
#endif /* CONFIG_NO_HZ_COMMON */
|
2010-05-22 00:09:41 +00:00
|
|
|
|
2018-02-20 10:45:47 +00:00
|
|
|
/*
|
|
|
|
* idle_balance is called by schedule() if this_cpu is about to become
|
|
|
|
* idle. Attempts to pull tasks from other CPUs.
|
2019-11-08 13:15:55 +00:00
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* < 0 - we released the lock and there are !fair tasks present
|
|
|
|
* 0 - failed, no new tasks
|
|
|
|
* > 0 - success, new (fair) tasks present
|
2018-02-20 10:45:47 +00:00
|
|
|
*/
|
2019-05-29 20:36:42 +00:00
|
|
|
int newidle_balance(struct rq *this_rq, struct rq_flags *rf)
|
2018-02-20 10:45:47 +00:00
|
|
|
{
|
|
|
|
unsigned long next_balance = jiffies + HZ;
|
|
|
|
int this_cpu = this_rq->cpu;
|
|
|
|
struct sched_domain *sd;
|
|
|
|
int pulled_task = 0;
|
|
|
|
u64 curr_cost = 0;
|
|
|
|
|
2019-05-29 20:36:42 +00:00
|
|
|
update_misfit_status(NULL, this_rq);
|
2018-02-20 10:45:47 +00:00
|
|
|
/*
|
|
|
|
* We must set idle_stamp _before_ calling idle_balance(), such that we
|
|
|
|
* measure the duration of idle_balance() as idle time.
|
|
|
|
*/
|
|
|
|
this_rq->idle_stamp = rq_clock(this_rq);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do not pull tasks towards !active CPUs...
|
|
|
|
*/
|
|
|
|
if (!cpu_active(this_cpu))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is OK, because current is on_cpu, which avoids it being picked
|
|
|
|
* for load-balance and preemption/IRQs are still disabled avoiding
|
|
|
|
* further scheduler activity on it and we're being very careful to
|
|
|
|
* re-start the picking loop.
|
|
|
|
*/
|
|
|
|
rq_unpin_lock(this_rq, rf);
|
|
|
|
|
|
|
|
if (this_rq->avg_idle < sysctl_sched_migration_cost ||
|
2018-07-04 10:17:46 +00:00
|
|
|
!READ_ONCE(this_rq->rd->overload)) {
|
2018-02-14 15:26:46 +00:00
|
|
|
|
2018-02-20 10:45:47 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
sd = rcu_dereference_check_sched_domain(this_rq->sd);
|
|
|
|
if (sd)
|
|
|
|
update_next_balance(sd, &next_balance);
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
2018-02-14 15:26:46 +00:00
|
|
|
nohz_newidle_balance(this_rq);
|
|
|
|
|
2018-02-20 10:45:47 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
raw_spin_unlock(&this_rq->lock);
|
|
|
|
|
|
|
|
update_blocked_averages(this_cpu);
|
|
|
|
rcu_read_lock();
|
|
|
|
for_each_domain(this_cpu, sd) {
|
|
|
|
int continue_balancing = 1;
|
|
|
|
u64 t0, domain_cost;
|
|
|
|
|
|
|
|
if (!(sd->flags & SD_LOAD_BALANCE))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (this_rq->avg_idle < curr_cost + sd->max_newidle_lb_cost) {
|
|
|
|
update_next_balance(sd, &next_balance);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sd->flags & SD_BALANCE_NEWIDLE) {
|
|
|
|
t0 = sched_clock_cpu(this_cpu);
|
|
|
|
|
|
|
|
pulled_task = load_balance(this_cpu, this_rq,
|
|
|
|
sd, CPU_NEWLY_IDLE,
|
|
|
|
&continue_balancing);
|
|
|
|
|
|
|
|
domain_cost = sched_clock_cpu(this_cpu) - t0;
|
|
|
|
if (domain_cost > sd->max_newidle_lb_cost)
|
|
|
|
sd->max_newidle_lb_cost = domain_cost;
|
|
|
|
|
|
|
|
curr_cost += domain_cost;
|
|
|
|
}
|
|
|
|
|
|
|
|
update_next_balance(sd, &next_balance);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Stop searching for tasks to pull if there are
|
|
|
|
* now runnable tasks on this rq.
|
|
|
|
*/
|
|
|
|
if (pulled_task || this_rq->nr_running > 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
raw_spin_lock(&this_rq->lock);
|
|
|
|
|
|
|
|
if (curr_cost > this_rq->max_idle_balance_cost)
|
|
|
|
this_rq->max_idle_balance_cost = curr_cost;
|
|
|
|
|
2018-04-26 10:19:32 +00:00
|
|
|
out:
|
2018-02-20 10:45:47 +00:00
|
|
|
/*
|
|
|
|
* While browsing the domains, we released the rq lock, a task could
|
|
|
|
* have been enqueued in the meantime. Since we're not going idle,
|
|
|
|
* pretend we pulled a task.
|
|
|
|
*/
|
|
|
|
if (this_rq->cfs.h_nr_running && !pulled_task)
|
|
|
|
pulled_task = 1;
|
|
|
|
|
|
|
|
/* Move the next balance forward */
|
|
|
|
if (time_after(this_rq->next_balance, next_balance))
|
|
|
|
this_rq->next_balance = next_balance;
|
|
|
|
|
|
|
|
/* Is there a task of a high priority class? */
|
|
|
|
if (this_rq->nr_running != this_rq->cfs.h_nr_running)
|
|
|
|
pulled_task = -1;
|
|
|
|
|
|
|
|
if (pulled_task)
|
|
|
|
this_rq->idle_stamp = 0;
|
|
|
|
|
|
|
|
rq_repin_lock(this_rq, rf);
|
|
|
|
|
|
|
|
return pulled_task;
|
|
|
|
}
|
|
|
|
|
2010-05-22 00:09:41 +00:00
|
|
|
/*
|
|
|
|
* run_rebalance_domains is triggered when needed from the scheduler tick.
|
|
|
|
* Also triggered for nohz idle balancing (with nohz_balancing_kick set).
|
|
|
|
*/
|
2016-06-20 18:42:34 +00:00
|
|
|
static __latent_entropy void run_rebalance_domains(struct softirq_action *h)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
2014-01-06 11:34:44 +00:00
|
|
|
struct rq *this_rq = this_rq();
|
2011-10-03 22:09:01 +00:00
|
|
|
enum cpu_idle_type idle = this_rq->idle_balance ?
|
2009-12-17 16:00:43 +00:00
|
|
|
CPU_IDLE : CPU_NOT_IDLE;
|
|
|
|
|
|
|
|
/*
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* If this CPU has a pending nohz_balance_kick, then do the
|
|
|
|
* balancing on behalf of the other idle CPUs whose ticks are
|
sched: Improve load balancing in the presence of idle CPUs
When a CPU is kicked to do nohz idle balancing, it wakes up to do load
balancing on itself, followed by load balancing on behalf of idle CPUs.
But it may end up with load after the load balancing attempt on itself.
This aborts nohz idle balancing. As a result several idle CPUs are left
without tasks till such a time that an ILB CPU finds it unfavorable to
pull tasks upon itself. This delays spreading of load across idle CPUs
and worse, clutters only a few CPUs with tasks.
The effect of the above problem was observed on an SMT8 POWER server
with 2 levels of numa domains. Busy loops equal to number of cores were
spawned. Since load balancing on fork/exec is discouraged across numa
domains, all busy loops would start on one of the numa domains. However
it was expected that eventually one busy loop would run per core across
all domains due to nohz idle load balancing. But it was observed that it
took as long as 10 seconds to spread the load across numa domains.
Further investigation showed that this was a consequence of the
following:
1. An ILB CPU was chosen from the first numa domain to trigger nohz idle
load balancing [Given the experiment, upto 6 CPUs per core could be
potentially idle in this domain.]
2. However the ILB CPU would call load_balance() on itself before
initiating nohz idle load balancing.
3. Given cores are SMT8, the ILB CPU had enough opportunities to pull
tasks from its sibling cores to even out load.
4. Now that the ILB CPU was no longer idle, it would abort nohz idle
load balancing
As a result the opportunities to spread load across numa domains were
lost until such a time that the cores within the first numa domain had
equal number of tasks among themselves. This is a pretty bad scenario,
since the cores within the first numa domain would have as many as 4
tasks each, while cores in the neighbouring numa domains would all
remain idle.
Fix this, by checking if a CPU was woken up to do nohz idle load
balancing, before it does load balancing upon itself. This way we allow
idle CPUs across the system to do load balancing which results in
quicker spread of load, instead of performing load balancing within the
local sched domain hierarchy of the ILB CPU alone under circumstances
such as above.
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Jason Low <jason.low2@hp.com>
Cc: benh@kernel.crashing.org
Cc: daniel.lezcano@linaro.org
Cc: efault@gmx.de
Cc: iamjoonsoo.kim@lge.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: riel@redhat.com
Cc: srikar@linux.vnet.ibm.com
Cc: svaidy@linux.vnet.ibm.com
Cc: tim.c.chen@linux.intel.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/20150326130014.21532.17158.stgit@preeti.in.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-26 13:02:44 +00:00
|
|
|
* stopped. Do nohz_idle_balance *before* rebalance_domains to
|
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 13:01:12 +00:00
|
|
|
* give the idle CPUs a chance to load balance. Else we may
|
sched: Improve load balancing in the presence of idle CPUs
When a CPU is kicked to do nohz idle balancing, it wakes up to do load
balancing on itself, followed by load balancing on behalf of idle CPUs.
But it may end up with load after the load balancing attempt on itself.
This aborts nohz idle balancing. As a result several idle CPUs are left
without tasks till such a time that an ILB CPU finds it unfavorable to
pull tasks upon itself. This delays spreading of load across idle CPUs
and worse, clutters only a few CPUs with tasks.
The effect of the above problem was observed on an SMT8 POWER server
with 2 levels of numa domains. Busy loops equal to number of cores were
spawned. Since load balancing on fork/exec is discouraged across numa
domains, all busy loops would start on one of the numa domains. However
it was expected that eventually one busy loop would run per core across
all domains due to nohz idle load balancing. But it was observed that it
took as long as 10 seconds to spread the load across numa domains.
Further investigation showed that this was a consequence of the
following:
1. An ILB CPU was chosen from the first numa domain to trigger nohz idle
load balancing [Given the experiment, upto 6 CPUs per core could be
potentially idle in this domain.]
2. However the ILB CPU would call load_balance() on itself before
initiating nohz idle load balancing.
3. Given cores are SMT8, the ILB CPU had enough opportunities to pull
tasks from its sibling cores to even out load.
4. Now that the ILB CPU was no longer idle, it would abort nohz idle
load balancing
As a result the opportunities to spread load across numa domains were
lost until such a time that the cores within the first numa domain had
equal number of tasks among themselves. This is a pretty bad scenario,
since the cores within the first numa domain would have as many as 4
tasks each, while cores in the neighbouring numa domains would all
remain idle.
Fix this, by checking if a CPU was woken up to do nohz idle load
balancing, before it does load balancing upon itself. This way we allow
idle CPUs across the system to do load balancing which results in
quicker spread of load, instead of performing load balancing within the
local sched domain hierarchy of the ILB CPU alone under circumstances
such as above.
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Jason Low <jason.low2@hp.com>
Cc: benh@kernel.crashing.org
Cc: daniel.lezcano@linaro.org
Cc: efault@gmx.de
Cc: iamjoonsoo.kim@lge.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: riel@redhat.com
Cc: srikar@linux.vnet.ibm.com
Cc: svaidy@linux.vnet.ibm.com
Cc: tim.c.chen@linux.intel.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/20150326130014.21532.17158.stgit@preeti.in.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-26 13:02:44 +00:00
|
|
|
* load balance only within the local sched_domain hierarchy
|
|
|
|
* and abort nohz_idle_balance altogether if we pull some load.
|
2009-12-17 16:00:43 +00:00
|
|
|
*/
|
2017-12-21 09:11:09 +00:00
|
|
|
if (nohz_idle_balance(this_rq, idle))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* normal load balance */
|
|
|
|
update_blocked_averages(this_rq->cpu);
|
sched: Improve load balancing in the presence of idle CPUs
When a CPU is kicked to do nohz idle balancing, it wakes up to do load
balancing on itself, followed by load balancing on behalf of idle CPUs.
But it may end up with load after the load balancing attempt on itself.
This aborts nohz idle balancing. As a result several idle CPUs are left
without tasks till such a time that an ILB CPU finds it unfavorable to
pull tasks upon itself. This delays spreading of load across idle CPUs
and worse, clutters only a few CPUs with tasks.
The effect of the above problem was observed on an SMT8 POWER server
with 2 levels of numa domains. Busy loops equal to number of cores were
spawned. Since load balancing on fork/exec is discouraged across numa
domains, all busy loops would start on one of the numa domains. However
it was expected that eventually one busy loop would run per core across
all domains due to nohz idle load balancing. But it was observed that it
took as long as 10 seconds to spread the load across numa domains.
Further investigation showed that this was a consequence of the
following:
1. An ILB CPU was chosen from the first numa domain to trigger nohz idle
load balancing [Given the experiment, upto 6 CPUs per core could be
potentially idle in this domain.]
2. However the ILB CPU would call load_balance() on itself before
initiating nohz idle load balancing.
3. Given cores are SMT8, the ILB CPU had enough opportunities to pull
tasks from its sibling cores to even out load.
4. Now that the ILB CPU was no longer idle, it would abort nohz idle
load balancing
As a result the opportunities to spread load across numa domains were
lost until such a time that the cores within the first numa domain had
equal number of tasks among themselves. This is a pretty bad scenario,
since the cores within the first numa domain would have as many as 4
tasks each, while cores in the neighbouring numa domains would all
remain idle.
Fix this, by checking if a CPU was woken up to do nohz idle load
balancing, before it does load balancing upon itself. This way we allow
idle CPUs across the system to do load balancing which results in
quicker spread of load, instead of performing load balancing within the
local sched domain hierarchy of the ILB CPU alone under circumstances
such as above.
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Jason Low <jason.low2@hp.com>
Cc: benh@kernel.crashing.org
Cc: daniel.lezcano@linaro.org
Cc: efault@gmx.de
Cc: iamjoonsoo.kim@lge.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: riel@redhat.com
Cc: srikar@linux.vnet.ibm.com
Cc: svaidy@linux.vnet.ibm.com
Cc: tim.c.chen@linux.intel.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/20150326130014.21532.17158.stgit@preeti.in.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-03-26 13:02:44 +00:00
|
|
|
rebalance_domains(this_rq, idle);
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Trigger the SCHED_SOFTIRQ if it is time to do periodic load balancing.
|
|
|
|
*/
|
2014-01-06 11:34:38 +00:00
|
|
|
void trigger_load_balance(struct rq *rq)
|
2009-12-17 16:00:43 +00:00
|
|
|
{
|
|
|
|
/* Don't need to rebalance while attached to NULL domain */
|
2014-01-06 11:34:45 +00:00
|
|
|
if (unlikely(on_null_domain(rq)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (time_after_eq(jiffies, rq->next_balance))
|
2009-12-17 16:00:43 +00:00
|
|
|
raise_softirq(SCHED_SOFTIRQ);
|
2017-12-21 09:47:48 +00:00
|
|
|
|
|
|
|
nohz_balancer_kick(rq);
|
2009-12-17 16:00:43 +00:00
|
|
|
}
|
|
|
|
|
2009-11-30 11:16:46 +00:00
|
|
|
static void rq_online_fair(struct rq *rq)
|
|
|
|
{
|
|
|
|
update_sysctl();
|
2014-06-25 08:19:42 +00:00
|
|
|
|
|
|
|
update_runtime_enabled(rq);
|
2009-11-30 11:16:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void rq_offline_fair(struct rq *rq)
|
|
|
|
{
|
|
|
|
update_sysctl();
|
2012-08-09 22:34:47 +00:00
|
|
|
|
|
|
|
/* Ensure any throttled groups are reachable by pick_next_task */
|
|
|
|
unthrottle_offline_cfs_rqs(rq);
|
2009-11-30 11:16:46 +00:00
|
|
|
}
|
|
|
|
|
2008-06-24 18:09:43 +00:00
|
|
|
#endif /* CONFIG_SMP */
|
2007-10-24 16:23:51 +00:00
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
2018-02-21 04:17:27 +00:00
|
|
|
* scheduler tick hitting a task of our scheduling class.
|
|
|
|
*
|
|
|
|
* NOTE: This function can be called remotely by the tick offload that
|
|
|
|
* goes along full dynticks. Therefore no local assumption can be made
|
|
|
|
* and everything must be accessed through the @rq and @curr passed in
|
|
|
|
* parameters.
|
2007-07-09 16:51:58 +00:00
|
|
|
*/
|
2008-01-25 20:08:29 +00:00
|
|
|
static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq;
|
|
|
|
struct sched_entity *se = &curr->se;
|
|
|
|
|
|
|
|
for_each_sched_entity(se) {
|
|
|
|
cfs_rq = cfs_rq_of(se);
|
2008-01-25 20:08:29 +00:00
|
|
|
entity_tick(cfs_rq, se, queued);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
2012-10-04 10:51:20 +00:00
|
|
|
|
2015-10-02 02:18:25 +00:00
|
|
|
if (static_branch_unlikely(&sched_numa_balancing))
|
2012-10-25 12:16:43 +00:00
|
|
|
task_tick_numa(rq, curr);
|
2018-07-04 10:17:40 +00:00
|
|
|
|
|
|
|
update_misfit_status(curr, rq);
|
sched/fair: Add over-utilization/tipping point indicator
Energy-aware scheduling is only meant to be active while the system is
_not_ over-utilized. That is, there are spare cycles available to shift
tasks around based on their actual utilization to get a more
energy-efficient task distribution without depriving any tasks. When
above the tipping point task placement is done the traditional way based
on load_avg, spreading the tasks across as many cpus as possible based
on priority scaled load to preserve smp_nice. Below the tipping point we
want to use util_avg instead. We need to define a criteria for when we
make the switch.
The util_avg for each cpu converges towards 100% regardless of how many
additional tasks we may put on it. If we define over-utilized as:
sum_{cpus}(rq.cfs.avg.util_avg) + margin > sum_{cpus}(rq.capacity)
some individual cpus may be over-utilized running multiple tasks even
when the above condition is false. That should be okay as long as we try
to spread the tasks out to avoid per-cpu over-utilization as much as
possible and if all tasks have the _same_ priority. If the latter isn't
true, we have to consider priority to preserve smp_nice.
For example, we could have n_cpus nice=-10 util_avg=55% tasks and
n_cpus/2 nice=0 util_avg=60% tasks. Balancing based on util_avg we are
likely to end up with nice=-10 tasks sharing cpus and nice=0 tasks
getting their own as we 1.5*n_cpus tasks in total and 55%+55% is less
over-utilized than 55%+60% for those cpus that have to be shared. The
system utilization is only 85% of the system capacity, but we are
breaking smp_nice.
To be sure not to break smp_nice, we have defined over-utilization
conservatively as when any cpu in the system is fully utilized at its
highest frequency instead:
cpu_rq(any).cfs.avg.util_avg + margin > cpu_rq(any).capacity
IOW, as soon as one cpu is (nearly) 100% utilized, we switch to load_avg
to factor in priority to preserve smp_nice.
With this definition, we can skip periodic load-balance as no cpu has an
always-running task when the system is not over-utilized. All tasks will
be periodic and we can balance them at wake-up. This conservative
condition does however mean that some scenarios that could benefit from
energy-aware decisions even if one cpu is fully utilized would not get
those benefits.
For systems where some cpus might have reduced capacity on some cpus
(RT-pressure and/or big.LITTLE), we want periodic load-balance checks as
soon a just a single cpu is fully utilized as it might one of those with
reduced capacity and in that case we want to migrate it.
[ peterz: Added a comment explaining why new tasks are not accounted during
overutilization detection. ]
Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com>
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: adharmap@codeaurora.org
Cc: chris.redpath@arm.com
Cc: currojerez@riseup.net
Cc: dietmar.eggemann@arm.com
Cc: edubezval@gmail.com
Cc: gregkh@linuxfoundation.org
Cc: javi.merino@kernel.org
Cc: joel@joelfernandes.org
Cc: juri.lelli@redhat.com
Cc: patrick.bellasi@arm.com
Cc: pkondeti@codeaurora.org
Cc: rjw@rjwysocki.net
Cc: skannan@codeaurora.org
Cc: smuckle@google.com
Cc: srinivas.pandruvada@linux.intel.com
Cc: thara.gopinath@linaro.org
Cc: tkjos@google.com
Cc: valentin.schneider@arm.com
Cc: vincent.guittot@linaro.org
Cc: viresh.kumar@linaro.org
Link: https://lkml.kernel.org/r/20181203095628.11858-13-quentin.perret@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-12-03 09:56:25 +00:00
|
|
|
update_overutilized_status(task_rq(curr));
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2009-11-27 16:32:46 +00:00
|
|
|
* called on fork with the child task as argument from the parent's context
|
|
|
|
* - child not yet on the tasklist
|
|
|
|
* - preemption disabled
|
2007-07-09 16:51:58 +00:00
|
|
|
*/
|
2009-11-27 16:32:46 +00:00
|
|
|
static void task_fork_fair(struct task_struct *p)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2011-12-15 05:36:55 +00:00
|
|
|
struct cfs_rq *cfs_rq;
|
|
|
|
struct sched_entity *se = &p->se, *curr;
|
2009-11-27 16:32:46 +00:00
|
|
|
struct rq *rq = this_rq();
|
2016-10-04 14:04:35 +00:00
|
|
|
struct rq_flags rf;
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_lock(rq, &rf);
|
2010-08-19 11:31:43 +00:00
|
|
|
update_rq_clock(rq);
|
|
|
|
|
2011-12-15 05:36:55 +00:00
|
|
|
cfs_rq = task_cfs_rq(current);
|
|
|
|
curr = cfs_rq->curr;
|
2016-06-16 16:51:48 +00:00
|
|
|
if (curr) {
|
|
|
|
update_curr(cfs_rq);
|
sched: Ensure that a child can't gain time over it's parent after fork()
A fork/exec load is usually "pass the baton", so the child
should never be placed behind the parent. With START_DEBIT we
make room for the new task, but with child_runs_first, that
room comes out of the _parent's_ hide. There's nothing to say
that the parent wasn't ahead of min_vruntime at fork() time,
which means that the "baton carrier", who is essentially the
parent in drag, can gain time and increase scheduling latencies
for waiters.
With NEW_FAIR_SLEEPERS + START_DEBIT + child_runs_first
enabled, we essentially pass the sleeper fairness off to the
child, which is fine, but if we don't base placement on the
parent's updated vruntime, we can end up compounding latency
woes if the child itself then does fork/exec. The debit
incurred at fork doesn't hurt the parent who is then going to
sleep and maybe exit, but the child who acquires the error
harms all comers.
This improves latencies of make -j<n> kernel build workloads.
Reported-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-08 09:12:28 +00:00
|
|
|
se->vruntime = curr->vruntime;
|
2016-06-16 16:51:48 +00:00
|
|
|
}
|
2007-10-15 15:00:05 +00:00
|
|
|
place_entity(cfs_rq, se, 1);
|
2007-10-15 15:00:04 +00:00
|
|
|
|
2009-11-27 16:32:46 +00:00
|
|
|
if (sysctl_sched_child_runs_first && curr && entity_before(curr, se)) {
|
2007-10-15 15:00:08 +00:00
|
|
|
/*
|
2007-10-15 15:00:08 +00:00
|
|
|
* Upon rescheduling, sched_class::put_prev_task() will place
|
|
|
|
* 'current' within the tree based on its new key value.
|
|
|
|
*/
|
2007-10-15 15:00:04 +00:00
|
|
|
swap(curr->vruntime, se->vruntime);
|
2014-06-28 20:03:57 +00:00
|
|
|
resched_curr(rq);
|
2007-10-15 15:00:04 +00:00
|
|
|
}
|
2007-07-09 16:51:58 +00:00
|
|
|
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
se->vruntime -= cfs_rq->min_vruntime;
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_unlock(rq, &rf);
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
|
|
|
|
2008-01-25 20:08:22 +00:00
|
|
|
/*
|
|
|
|
* Priority of the task has changed. Check to see if we preempt
|
|
|
|
* the current task.
|
|
|
|
*/
|
2011-01-17 16:03:27 +00:00
|
|
|
static void
|
|
|
|
prio_changed_fair(struct rq *rq, struct task_struct *p, int oldprio)
|
2008-01-25 20:08:22 +00:00
|
|
|
{
|
2014-08-20 09:47:32 +00:00
|
|
|
if (!task_on_rq_queued(p))
|
2011-01-17 16:03:27 +00:00
|
|
|
return;
|
|
|
|
|
2019-12-03 16:01:05 +00:00
|
|
|
if (rq->cfs.nr_running == 1)
|
|
|
|
return;
|
|
|
|
|
2008-01-25 20:08:22 +00:00
|
|
|
/*
|
|
|
|
* Reschedule if we are currently running on this runqueue and
|
|
|
|
* our priority decreased, or if we are not currently running on
|
|
|
|
* this runqueue and our priority is higher than the current's
|
|
|
|
*/
|
2011-01-17 16:03:27 +00:00
|
|
|
if (rq->curr == p) {
|
2008-01-25 20:08:22 +00:00
|
|
|
if (p->prio > oldprio)
|
2014-06-28 20:03:57 +00:00
|
|
|
resched_curr(rq);
|
2008-01-25 20:08:22 +00:00
|
|
|
} else
|
2008-09-20 21:38:02 +00:00
|
|
|
check_preempt_curr(rq, p, 0);
|
2008-01-25 20:08:22 +00:00
|
|
|
}
|
|
|
|
|
2015-08-20 11:22:00 +00:00
|
|
|
static inline bool vruntime_normalized(struct task_struct *p)
|
2011-01-17 16:03:27 +00:00
|
|
|
{
|
|
|
|
struct sched_entity *se = &p->se;
|
|
|
|
|
|
|
|
/*
|
2015-08-20 11:22:00 +00:00
|
|
|
* In both the TASK_ON_RQ_QUEUED and TASK_ON_RQ_MIGRATING cases,
|
|
|
|
* the dequeue_entity(.flags=0) will already have normalized the
|
|
|
|
* vruntime.
|
|
|
|
*/
|
|
|
|
if (p->on_rq)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When !on_rq, vruntime of the task has usually NOT been normalized.
|
|
|
|
* But there are some cases where it has already been normalized:
|
2011-01-17 16:03:27 +00:00
|
|
|
*
|
2015-08-20 11:22:00 +00:00
|
|
|
* - A forked child which is waiting for being woken up by
|
|
|
|
* wake_up_new_task().
|
|
|
|
* - A task which has been woken up by try_to_wake_up() and
|
|
|
|
* waiting for actually being woken up by sched_ttwu_pending().
|
2011-01-17 16:03:27 +00:00
|
|
|
*/
|
2018-08-31 22:42:17 +00:00
|
|
|
if (!se->sum_exec_runtime ||
|
|
|
|
(p->state == TASK_WAKING && p->sched_remote_wakeup))
|
2015-08-20 11:22:00 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-11-08 09:53:45 +00:00
|
|
|
#ifdef CONFIG_FAIR_GROUP_SCHED
|
|
|
|
/*
|
|
|
|
* Propagate the changes of the sched_entity across the tg tree to make it
|
|
|
|
* visible to the root
|
|
|
|
*/
|
|
|
|
static void propagate_entity_cfs_rq(struct sched_entity *se)
|
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq;
|
|
|
|
|
|
|
|
/* Start to propagate at parent */
|
|
|
|
se = se->parent;
|
|
|
|
|
|
|
|
for_each_sched_entity(se) {
|
|
|
|
cfs_rq = cfs_rq_of(se);
|
|
|
|
|
|
|
|
if (cfs_rq_throttled(cfs_rq))
|
|
|
|
break;
|
|
|
|
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq, se, UPDATE_TG);
|
2016-11-08 09:53:45 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static void propagate_entity_cfs_rq(struct sched_entity *se) { }
|
|
|
|
#endif
|
|
|
|
|
2016-11-08 09:53:42 +00:00
|
|
|
static void detach_entity_cfs_rq(struct sched_entity *se)
|
2015-08-20 11:22:00 +00:00
|
|
|
{
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
|
|
|
|
sched/fair: Rewrite runnable load and utilization average tracking
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner and Ben Segall, and it is still followed by
this rewrite. This rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granularity of an entity at a time, which results in the
cfs_rq's load average is stale or partially updated: at any time, only
one entity is up to date, all other entities are effectively lagging
behind. This is undesirable.
To illustrate, if we have n runnable entities in the cfs_rq, as time
elapses, they certainly become outdated:
t0: cfs_rq { e1_old, e2_old, ..., en_old }
and when we update:
t1: update e1, then we have cfs_rq { e1_new, e2_old, ..., en_old }
t2: update e2, then we have cfs_rq { e1_old, e2_new, ..., en_old }
...
We solve this by combining all runnable entities' load averages together
in cfs_rq's avg, and update the cfs_rq's avg as a whole. This is based
on the fact that if we regard the update as a function, then:
w * update(e) = update(w * e) and
update(e1) + update(e2) = update(e1 + e2), then
w1 * update(e1) + w2 * update(e2) = update(w1 * e1 + w2 * e2)
therefore, by this rewrite, we have an entirely updated cfs_rq at the
time we update it:
t1: update cfs_rq { e1_new, e2_new, ..., en_new }
t2: update cfs_rq { e1_new, e2_new, ..., en_new }
...
2. cfs_rq's load average is different between top rq->cfs_rq and other
task_group's per CPU cfs_rqs in whether or not blocked_load_average
contributes to the load.
The basic idea behind runnable load average (the same for utilization)
is that the blocked state is taken into account as opposed to only
accounting for the currently runnable state. Therefore, the average
should include both the runnable/running and blocked load averages.
This rewrite does that.
In addition, we also combine runnable/running and blocked averages
of all entities into the cfs_rq's average, and update it together at
once. This is based on the fact that:
update(runnable) + update(blocked) = update(runnable + blocked)
This significantly reduces the code as we don't need to separately
maintain/update runnable/running load and blocked load.
3. How task_group entities' share is calculated is complex and imprecise.
We reduce the complexity in this rewrite to allow a very simple rule:
the task_group's load_avg is aggregated from its per CPU cfs_rqs's
load_avgs. Then group entity's weight is simply proportional to its
own cfs_rq's load_avg / task_group's load_avg. To illustrate,
if a task_group has { cfs_rq1, cfs_rq2, ..., cfs_rqn }, then,
task_group_avg = cfs_rq1_avg + cfs_rq2_avg + ... + cfs_rqn_avg, then
cfs_rqx's entity's share = cfs_rqx_avg / task_group_avg * task_group's share
To sum up, this rewrite in principle is equivalent to the current one, but
fixes the issues described above. Turns out, it significantly reduces the
code complexity and hence increases clarity and efficiency. In addition,
the new averages are more smooth/continuous (no spurious spikes and valleys)
and updated more consistently and quickly to reflect the load dynamics.
As a result, we have less load tracking overhead, better performance,
and especially better power efficiency due to more balanced load.
Signed-off-by: Yuyang Du <yuyang.du@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: arjan@linux.intel.com
Cc: bsegall@google.com
Cc: dietmar.eggemann@arm.com
Cc: fengguang.wu@intel.com
Cc: len.brown@intel.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: rafael.j.wysocki@intel.com
Cc: umgwanakikbuti@gmail.com
Cc: vincent.guittot@linaro.org
Link: http://lkml.kernel.org/r/1436918682-4971-3-git-send-email-yuyang.du@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-07-15 00:04:37 +00:00
|
|
|
/* Catch up with the cfs_rq and remove our load when we leave */
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq, se, 0);
|
2015-08-20 11:21:56 +00:00
|
|
|
detach_entity_load_avg(cfs_rq, se);
|
2016-07-13 08:56:25 +00:00
|
|
|
update_tg_load_avg(cfs_rq, false);
|
2016-11-08 09:53:45 +00:00
|
|
|
propagate_entity_cfs_rq(se);
|
2011-01-17 16:03:27 +00:00
|
|
|
}
|
|
|
|
|
2016-11-08 09:53:42 +00:00
|
|
|
static void attach_entity_cfs_rq(struct sched_entity *se)
|
2008-01-25 20:08:22 +00:00
|
|
|
{
|
2015-08-20 11:22:00 +00:00
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
2015-08-10 09:02:55 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_FAIR_GROUP_SCHED
|
2014-02-20 03:14:53 +00:00
|
|
|
/*
|
|
|
|
* Since the real-depth could have been changed (only FAIR
|
|
|
|
* class maintain depth value), reset depth properly.
|
|
|
|
*/
|
|
|
|
se->depth = se->parent ? se->parent->depth + 1 : 0;
|
|
|
|
#endif
|
2015-08-10 09:02:55 +00:00
|
|
|
|
2016-11-08 09:53:42 +00:00
|
|
|
/* Synchronize entity with its cfs_rq */
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq, se, sched_feat(ATTACH_AGE_LOAD) ? 0 : SKIP_AGE_LOAD);
|
2020-01-15 10:20:20 +00:00
|
|
|
attach_entity_load_avg(cfs_rq, se);
|
2016-07-13 08:56:25 +00:00
|
|
|
update_tg_load_avg(cfs_rq, false);
|
2016-11-08 09:53:45 +00:00
|
|
|
propagate_entity_cfs_rq(se);
|
2016-11-08 09:53:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void detach_task_cfs_rq(struct task_struct *p)
|
|
|
|
{
|
|
|
|
struct sched_entity *se = &p->se;
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
|
|
|
|
|
|
|
if (!vruntime_normalized(p)) {
|
|
|
|
/*
|
|
|
|
* Fix up our vruntime so that the current sleep doesn't
|
|
|
|
* cause 'unlimited' sleep bonus.
|
|
|
|
*/
|
|
|
|
place_entity(cfs_rq, se, 0);
|
|
|
|
se->vruntime -= cfs_rq->min_vruntime;
|
|
|
|
}
|
|
|
|
|
|
|
|
detach_entity_cfs_rq(se);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void attach_task_cfs_rq(struct task_struct *p)
|
|
|
|
{
|
|
|
|
struct sched_entity *se = &p->se;
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
|
|
|
|
|
|
|
attach_entity_cfs_rq(se);
|
2015-08-20 11:22:00 +00:00
|
|
|
|
|
|
|
if (!vruntime_normalized(p))
|
|
|
|
se->vruntime += cfs_rq->min_vruntime;
|
|
|
|
}
|
2015-08-20 11:21:59 +00:00
|
|
|
|
2015-08-20 11:22:00 +00:00
|
|
|
static void switched_from_fair(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
detach_task_cfs_rq(p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void switched_to_fair(struct rq *rq, struct task_struct *p)
|
|
|
|
{
|
|
|
|
attach_task_cfs_rq(p);
|
2015-08-10 09:02:55 +00:00
|
|
|
|
2015-08-20 11:22:00 +00:00
|
|
|
if (task_on_rq_queued(p)) {
|
2015-08-10 09:02:55 +00:00
|
|
|
/*
|
2015-08-20 11:22:00 +00:00
|
|
|
* We were most likely switched from sched_rt, so
|
|
|
|
* kick off the schedule if running, otherwise just see
|
|
|
|
* if we can still preempt the current task.
|
2015-08-10 09:02:55 +00:00
|
|
|
*/
|
2015-08-20 11:22:00 +00:00
|
|
|
if (rq->curr == p)
|
|
|
|
resched_curr(rq);
|
|
|
|
else
|
|
|
|
check_preempt_curr(rq, p, 0);
|
2015-08-10 09:02:55 +00:00
|
|
|
}
|
2008-01-25 20:08:22 +00:00
|
|
|
}
|
|
|
|
|
2007-10-15 15:00:08 +00:00
|
|
|
/* Account for a task changing its policy or group.
|
|
|
|
*
|
|
|
|
* This routine is mostly called to set cfs_rq->curr field when a task
|
|
|
|
* migrates between groups/classes.
|
|
|
|
*/
|
2019-11-08 13:16:00 +00:00
|
|
|
static void set_next_task_fair(struct rq *rq, struct task_struct *p, bool first)
|
2007-10-15 15:00:08 +00:00
|
|
|
{
|
2019-05-29 20:36:41 +00:00
|
|
|
struct sched_entity *se = &p->se;
|
|
|
|
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
if (task_on_rq_queued(p)) {
|
|
|
|
/*
|
|
|
|
* Move the next running task to the front of the list, so our
|
|
|
|
* cfs_tasks list becomes MRU one.
|
|
|
|
*/
|
|
|
|
list_move(&se->group_node, &rq->cfs_tasks);
|
|
|
|
}
|
|
|
|
#endif
|
2007-10-15 15:00:08 +00:00
|
|
|
|
2011-07-21 16:43:30 +00:00
|
|
|
for_each_sched_entity(se) {
|
|
|
|
struct cfs_rq *cfs_rq = cfs_rq_of(se);
|
|
|
|
|
|
|
|
set_next_entity(cfs_rq, se);
|
|
|
|
/* ensure bandwidth has been allocated on our new cfs_rq */
|
|
|
|
account_cfs_rq_runtime(cfs_rq, 0);
|
|
|
|
}
|
2007-10-15 15:00:08 +00:00
|
|
|
}
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
void init_cfs_rq(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
2017-09-08 23:14:55 +00:00
|
|
|
cfs_rq->tasks_timeline = RB_ROOT_CACHED;
|
2011-10-25 08:00:11 +00:00
|
|
|
cfs_rq->min_vruntime = (u64)(-(1LL << 20));
|
|
|
|
#ifndef CONFIG_64BIT
|
|
|
|
cfs_rq->min_vruntime_copy = cfs_rq->min_vruntime;
|
|
|
|
#endif
|
2013-06-26 05:05:39 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2017-05-08 14:51:41 +00:00
|
|
|
raw_spin_lock_init(&cfs_rq->removed.lock);
|
2012-10-04 11:18:30 +00:00
|
|
|
#endif
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
2008-02-29 20:21:01 +00:00
|
|
|
#ifdef CONFIG_FAIR_GROUP_SCHED
|
2016-06-17 11:38:55 +00:00
|
|
|
static void task_set_group_fair(struct task_struct *p)
|
|
|
|
{
|
|
|
|
struct sched_entity *se = &p->se;
|
|
|
|
|
|
|
|
set_task_rq(p, task_cpu(p));
|
|
|
|
se->depth = se->parent ? se->parent->depth + 1 : 0;
|
|
|
|
}
|
|
|
|
|
2015-08-31 15:13:55 +00:00
|
|
|
static void task_move_group_fair(struct task_struct *p)
|
2008-02-29 20:21:01 +00:00
|
|
|
{
|
2015-08-20 11:22:00 +00:00
|
|
|
detach_task_cfs_rq(p);
|
2010-10-15 13:24:15 +00:00
|
|
|
set_task_rq(p, task_cpu(p));
|
2015-08-20 11:21:59 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
/* Tell se's cfs_rq has been changed -- migrated */
|
|
|
|
p->se.avg.last_update_time = 0;
|
|
|
|
#endif
|
2015-08-20 11:22:00 +00:00
|
|
|
attach_task_cfs_rq(p);
|
2008-02-29 20:21:01 +00:00
|
|
|
}
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2016-06-17 11:38:55 +00:00
|
|
|
static void task_change_group_fair(struct task_struct *p, int type)
|
|
|
|
{
|
|
|
|
switch (type) {
|
|
|
|
case TASK_SET_GROUP:
|
|
|
|
task_set_group_fair(p);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case TASK_MOVE_GROUP:
|
|
|
|
task_move_group_fair(p);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-10-25 08:00:11 +00:00
|
|
|
void free_fair_sched_group(struct task_group *tg)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
destroy_cfs_bandwidth(tg_cfs_bandwidth(tg));
|
|
|
|
|
|
|
|
for_each_possible_cpu(i) {
|
|
|
|
if (tg->cfs_rq)
|
|
|
|
kfree(tg->cfs_rq[i]);
|
2016-01-21 21:24:16 +00:00
|
|
|
if (tg->se)
|
2011-10-25 08:00:11 +00:00
|
|
|
kfree(tg->se[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
kfree(tg->cfs_rq);
|
|
|
|
kfree(tg->se);
|
|
|
|
}
|
|
|
|
|
|
|
|
int alloc_fair_sched_group(struct task_group *tg, struct task_group *parent)
|
|
|
|
{
|
|
|
|
struct sched_entity *se;
|
sched/fair: Fix post_init_entity_util_avg() serialization
Chris Wilson reported a divide by 0 at:
post_init_entity_util_avg():
> 725 if (cfs_rq->avg.util_avg != 0) {
> 726 sa->util_avg = cfs_rq->avg.util_avg * se->load.weight;
> -> 727 sa->util_avg /= (cfs_rq->avg.load_avg + 1);
> 728
> 729 if (sa->util_avg > cap)
> 730 sa->util_avg = cap;
> 731 } else {
Which given the lack of serialization, and the code generated from
update_cfs_rq_load_avg() is entirely possible:
if (atomic_long_read(&cfs_rq->removed_load_avg)) {
s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
sa->load_avg = max_t(long, sa->load_avg - r, 0);
sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
removed_load = 1;
}
turns into:
ffffffff81087064: 49 8b 85 98 00 00 00 mov 0x98(%r13),%rax
ffffffff8108706b: 48 85 c0 test %rax,%rax
ffffffff8108706e: 74 40 je ffffffff810870b0
ffffffff81087070: 4c 89 f8 mov %r15,%rax
ffffffff81087073: 49 87 85 98 00 00 00 xchg %rax,0x98(%r13)
ffffffff8108707a: 49 29 45 70 sub %rax,0x70(%r13)
ffffffff8108707e: 4c 89 f9 mov %r15,%rcx
ffffffff81087081: bb 01 00 00 00 mov $0x1,%ebx
ffffffff81087086: 49 83 7d 70 00 cmpq $0x0,0x70(%r13)
ffffffff8108708b: 49 0f 49 4d 70 cmovns 0x70(%r13),%rcx
Which you'll note ends up with 'sa->load_avg - r' in memory at
ffffffff8108707a.
By calling post_init_entity_util_avg() under rq->lock we're sure to be
fully serialized against PELT updates and cannot observe intermediate
state like this.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yuyang Du <yuyang.du@intel.com>
Cc: bsegall@google.com
Cc: morten.rasmussen@arm.com
Cc: pjt@google.com
Cc: steve.muckle@linaro.org
Fixes: 2b8c41daba32 ("sched/fair: Initiate a new task's util avg to a bounded value")
Link: http://lkml.kernel.org/r/20160609130750.GQ30909@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-06-09 13:07:50 +00:00
|
|
|
struct cfs_rq *cfs_rq;
|
2011-10-25 08:00:11 +00:00
|
|
|
int i;
|
|
|
|
|
treewide: kzalloc() -> kcalloc()
The kzalloc() function has a 2-factor argument form, kcalloc(). This
patch replaces cases of:
kzalloc(a * b, gfp)
with:
kcalloc(a * b, gfp)
as well as handling cases of:
kzalloc(a * b * c, gfp)
with:
kzalloc(array3_size(a, b, c), gfp)
as it's slightly less ugly than:
kzalloc_array(array_size(a, b), c, gfp)
This does, however, attempt to ignore constant size factors like:
kzalloc(4 * 1024, gfp)
though any constants defined via macros get caught up in the conversion.
Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.
The Coccinelle script used for this was:
// Fix redundant parens around sizeof().
@@
type TYPE;
expression THING, E;
@@
(
kzalloc(
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
kzalloc(
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)
// Drop single-byte sizes and redundant parens.
@@
expression COUNT;
typedef u8;
typedef __u8;
@@
(
kzalloc(
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(char) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)
// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@
(
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)
// 2-factor product, only identifiers.
@@
identifier SIZE, COUNT;
@@
- kzalloc
+ kcalloc
(
- SIZE * COUNT
+ COUNT, SIZE
, ...)
// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@
(
kzalloc(
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)
// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@
(
kzalloc(
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kzalloc(
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)
// 3-factor product, only identifiers, with redundant parens removed.
@@
identifier STRIDE, SIZE, COUNT;
@@
(
kzalloc(
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)
// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression E1, E2, E3;
constant C1, C2, C3;
@@
(
kzalloc(C1 * C2 * C3, ...)
|
kzalloc(
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)
// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@
(
kzalloc(sizeof(THING) * C2, ...)
|
kzalloc(sizeof(TYPE) * C2, ...)
|
kzalloc(C1 * C2 * C3, ...)
|
kzalloc(C1 * C2, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- (E1) * E2
+ E1, E2
, ...)
|
- kzalloc
+ kcalloc
(
- (E1) * (E2)
+ E1, E2
, ...)
|
- kzalloc
+ kcalloc
(
- E1 * E2
+ E1, E2
, ...)
)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-12 21:03:40 +00:00
|
|
|
tg->cfs_rq = kcalloc(nr_cpu_ids, sizeof(cfs_rq), GFP_KERNEL);
|
2011-10-25 08:00:11 +00:00
|
|
|
if (!tg->cfs_rq)
|
|
|
|
goto err;
|
treewide: kzalloc() -> kcalloc()
The kzalloc() function has a 2-factor argument form, kcalloc(). This
patch replaces cases of:
kzalloc(a * b, gfp)
with:
kcalloc(a * b, gfp)
as well as handling cases of:
kzalloc(a * b * c, gfp)
with:
kzalloc(array3_size(a, b, c), gfp)
as it's slightly less ugly than:
kzalloc_array(array_size(a, b), c, gfp)
This does, however, attempt to ignore constant size factors like:
kzalloc(4 * 1024, gfp)
though any constants defined via macros get caught up in the conversion.
Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.
The Coccinelle script used for this was:
// Fix redundant parens around sizeof().
@@
type TYPE;
expression THING, E;
@@
(
kzalloc(
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
kzalloc(
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)
// Drop single-byte sizes and redundant parens.
@@
expression COUNT;
typedef u8;
typedef __u8;
@@
(
kzalloc(
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
kzalloc(
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(char) * COUNT
+ COUNT
, ...)
|
kzalloc(
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)
// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@
(
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)
// 2-factor product, only identifiers.
@@
identifier SIZE, COUNT;
@@
- kzalloc
+ kcalloc
(
- SIZE * COUNT
+ COUNT, SIZE
, ...)
// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@
(
kzalloc(
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kzalloc(
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kzalloc(
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)
// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@
(
kzalloc(
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kzalloc(
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
kzalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)
// 3-factor product, only identifiers, with redundant parens removed.
@@
identifier STRIDE, SIZE, COUNT;
@@
(
kzalloc(
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kzalloc(
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)
// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression E1, E2, E3;
constant C1, C2, C3;
@@
(
kzalloc(C1 * C2 * C3, ...)
|
kzalloc(
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
kzalloc(
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)
// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@
(
kzalloc(sizeof(THING) * C2, ...)
|
kzalloc(sizeof(TYPE) * C2, ...)
|
kzalloc(C1 * C2 * C3, ...)
|
kzalloc(C1 * C2, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- kzalloc
+ kcalloc
(
- (E1) * E2
+ E1, E2
, ...)
|
- kzalloc
+ kcalloc
(
- (E1) * (E2)
+ E1, E2
, ...)
|
- kzalloc
+ kcalloc
(
- E1 * E2
+ E1, E2
, ...)
)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-12 21:03:40 +00:00
|
|
|
tg->se = kcalloc(nr_cpu_ids, sizeof(se), GFP_KERNEL);
|
2011-10-25 08:00:11 +00:00
|
|
|
if (!tg->se)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
tg->shares = NICE_0_LOAD;
|
|
|
|
|
|
|
|
init_cfs_bandwidth(tg_cfs_bandwidth(tg));
|
|
|
|
|
|
|
|
for_each_possible_cpu(i) {
|
|
|
|
cfs_rq = kzalloc_node(sizeof(struct cfs_rq),
|
|
|
|
GFP_KERNEL, cpu_to_node(i));
|
|
|
|
if (!cfs_rq)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
se = kzalloc_node(sizeof(struct sched_entity),
|
|
|
|
GFP_KERNEL, cpu_to_node(i));
|
|
|
|
if (!se)
|
|
|
|
goto err_free_rq;
|
|
|
|
|
|
|
|
init_cfs_rq(cfs_rq);
|
|
|
|
init_tg_cfs_entry(tg, cfs_rq, se, i, parent->se[i]);
|
2015-07-15 00:04:39 +00:00
|
|
|
init_entity_runnable_average(se);
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
err_free_rq:
|
|
|
|
kfree(cfs_rq);
|
|
|
|
err:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-22 12:58:02 +00:00
|
|
|
void online_fair_sched_group(struct task_group *tg)
|
|
|
|
{
|
|
|
|
struct sched_entity *se;
|
2019-08-01 13:37:49 +00:00
|
|
|
struct rq_flags rf;
|
2016-06-22 12:58:02 +00:00
|
|
|
struct rq *rq;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for_each_possible_cpu(i) {
|
|
|
|
rq = cpu_rq(i);
|
|
|
|
se = tg->se[i];
|
2019-08-01 13:37:49 +00:00
|
|
|
rq_lock_irq(rq, &rf);
|
2016-10-03 14:20:59 +00:00
|
|
|
update_rq_clock(rq);
|
2016-11-08 09:53:47 +00:00
|
|
|
attach_entity_cfs_rq(se);
|
2016-06-22 13:14:26 +00:00
|
|
|
sync_throttle(tg, i);
|
2019-08-01 13:37:49 +00:00
|
|
|
rq_unlock_irq(rq, &rf);
|
2016-06-22 12:58:02 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-21 21:24:16 +00:00
|
|
|
void unregister_fair_sched_group(struct task_group *tg)
|
2011-10-25 08:00:11 +00:00
|
|
|
{
|
|
|
|
unsigned long flags;
|
2016-01-21 21:24:16 +00:00
|
|
|
struct rq *rq;
|
|
|
|
int cpu;
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2016-01-21 21:24:16 +00:00
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
if (tg->se[cpu])
|
|
|
|
remove_entity_load_avg(tg->se[cpu]);
|
2011-10-25 08:00:11 +00:00
|
|
|
|
2016-01-21 21:24:16 +00:00
|
|
|
/*
|
|
|
|
* Only empty task groups can be destroyed; so we can speculatively
|
|
|
|
* check on_list without danger of it being re-added.
|
|
|
|
*/
|
|
|
|
if (!tg->cfs_rq[cpu]->on_list)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
rq = cpu_rq(cpu);
|
|
|
|
|
|
|
|
raw_spin_lock_irqsave(&rq->lock, flags);
|
|
|
|
list_del_leaf_cfs_rq(tg->cfs_rq[cpu]);
|
|
|
|
raw_spin_unlock_irqrestore(&rq->lock, flags);
|
|
|
|
}
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void init_tg_cfs_entry(struct task_group *tg, struct cfs_rq *cfs_rq,
|
|
|
|
struct sched_entity *se, int cpu,
|
|
|
|
struct sched_entity *parent)
|
|
|
|
{
|
|
|
|
struct rq *rq = cpu_rq(cpu);
|
|
|
|
|
|
|
|
cfs_rq->tg = tg;
|
|
|
|
cfs_rq->rq = rq;
|
|
|
|
init_cfs_rq_runtime(cfs_rq);
|
|
|
|
|
|
|
|
tg->cfs_rq[cpu] = cfs_rq;
|
|
|
|
tg->se[cpu] = se;
|
|
|
|
|
|
|
|
/* se could be NULL for root_task_group */
|
|
|
|
if (!se)
|
|
|
|
return;
|
|
|
|
|
2012-02-11 05:05:00 +00:00
|
|
|
if (!parent) {
|
2011-10-25 08:00:11 +00:00
|
|
|
se->cfs_rq = &rq->cfs;
|
2012-02-11 05:05:00 +00:00
|
|
|
se->depth = 0;
|
|
|
|
} else {
|
2011-10-25 08:00:11 +00:00
|
|
|
se->cfs_rq = parent->my_q;
|
2012-02-11 05:05:00 +00:00
|
|
|
se->depth = parent->depth + 1;
|
|
|
|
}
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
se->my_q = cfs_rq;
|
sched: Guarantee new group-entities always have weight
Currently, group entity load-weights are initialized to zero. This
admits some races with respect to the first time they are re-weighted in
earlty use. ( Let g[x] denote the se for "g" on cpu "x". )
Suppose that we have root->a and that a enters a throttled state,
immediately followed by a[0]->t1 (the only task running on cpu[0])
blocking:
put_prev_task(group_cfs_rq(a[0]), t1)
put_prev_entity(..., t1)
check_cfs_rq_runtime(group_cfs_rq(a[0]))
throttle_cfs_rq(group_cfs_rq(a[0]))
Then, before unthrottling occurs, let a[0]->b[0]->t2 wake for the first
time:
enqueue_task_fair(rq[0], t2)
enqueue_entity(group_cfs_rq(b[0]), t2)
enqueue_entity_load_avg(group_cfs_rq(b[0]), t2)
account_entity_enqueue(group_cfs_ra(b[0]), t2)
update_cfs_shares(group_cfs_rq(b[0]))
< skipped because b is part of a throttled hierarchy >
enqueue_entity(group_cfs_rq(a[0]), b[0])
...
We now have b[0] enqueued, yet group_cfs_rq(a[0])->load.weight == 0
which violates invariants in several code-paths. Eliminate the
possibility of this by initializing group entity weight.
Signed-off-by: Paul Turner <pjt@google.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20131016181627.22647.47543.stgit@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-10-16 18:16:27 +00:00
|
|
|
/* guarantee group entities always have weight */
|
|
|
|
update_load_set(&se->load, NICE_0_LOAD);
|
2011-10-25 08:00:11 +00:00
|
|
|
se->parent = parent;
|
|
|
|
}
|
|
|
|
|
|
|
|
static DEFINE_MUTEX(shares_mutex);
|
|
|
|
|
|
|
|
int sched_group_set_shares(struct task_group *tg, unsigned long shares)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We can't change the weight of the root cgroup.
|
|
|
|
*/
|
|
|
|
if (!tg->se[0])
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
shares = clamp(shares, scale_load(MIN_SHARES), scale_load(MAX_SHARES));
|
|
|
|
|
|
|
|
mutex_lock(&shares_mutex);
|
|
|
|
if (tg->shares == shares)
|
|
|
|
goto done;
|
|
|
|
|
|
|
|
tg->shares = shares;
|
|
|
|
for_each_possible_cpu(i) {
|
|
|
|
struct rq *rq = cpu_rq(i);
|
2016-10-04 14:04:35 +00:00
|
|
|
struct sched_entity *se = tg->se[i];
|
|
|
|
struct rq_flags rf;
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
/* Propagate contribution to hierarchy */
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_lock_irqsave(rq, &rf);
|
2013-04-11 23:50:59 +00:00
|
|
|
update_rq_clock(rq);
|
2016-12-21 15:50:26 +00:00
|
|
|
for_each_sched_entity(se) {
|
2017-05-06 15:32:43 +00:00
|
|
|
update_load_avg(cfs_rq_of(se), se, UPDATE_TG);
|
2017-05-06 13:59:54 +00:00
|
|
|
update_cfs_group(se);
|
2016-12-21 15:50:26 +00:00
|
|
|
}
|
2016-10-04 14:04:35 +00:00
|
|
|
rq_unlock_irqrestore(rq, &rf);
|
2011-10-25 08:00:11 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
done:
|
|
|
|
mutex_unlock(&shares_mutex);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#else /* CONFIG_FAIR_GROUP_SCHED */
|
|
|
|
|
|
|
|
void free_fair_sched_group(struct task_group *tg) { }
|
|
|
|
|
|
|
|
int alloc_fair_sched_group(struct task_group *tg, struct task_group *parent)
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-06-22 12:58:02 +00:00
|
|
|
void online_fair_sched_group(struct task_group *tg) { }
|
|
|
|
|
2016-01-21 21:24:16 +00:00
|
|
|
void unregister_fair_sched_group(struct task_group *tg) { }
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
#endif /* CONFIG_FAIR_GROUP_SCHED */
|
|
|
|
|
2008-02-29 20:21:01 +00:00
|
|
|
|
2010-01-14 03:21:52 +00:00
|
|
|
static unsigned int get_rr_interval_fair(struct rq *rq, struct task_struct *task)
|
2009-09-21 01:31:53 +00:00
|
|
|
{
|
|
|
|
struct sched_entity *se = &task->se;
|
|
|
|
unsigned int rr_interval = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Time slice is 0 for SCHED_OTHER tasks that are on an otherwise
|
|
|
|
* idle runqueue:
|
|
|
|
*/
|
|
|
|
if (rq->cfs.load.weight)
|
2013-01-08 04:56:52 +00:00
|
|
|
rr_interval = NS_TO_JIFFIES(sched_slice(cfs_rq_of(se), se));
|
2009-09-21 01:31:53 +00:00
|
|
|
|
|
|
|
return rr_interval;
|
|
|
|
}
|
|
|
|
|
2007-07-09 16:51:58 +00:00
|
|
|
/*
|
|
|
|
* All the scheduling class methods:
|
|
|
|
*/
|
2011-10-25 08:00:11 +00:00
|
|
|
const struct sched_class fair_sched_class = {
|
2007-10-15 15:00:12 +00:00
|
|
|
.next = &idle_sched_class,
|
2007-07-09 16:51:58 +00:00
|
|
|
.enqueue_task = enqueue_task_fair,
|
|
|
|
.dequeue_task = dequeue_task_fair,
|
|
|
|
.yield_task = yield_task_fair,
|
2011-02-01 14:50:51 +00:00
|
|
|
.yield_to_task = yield_to_task_fair,
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2007-10-15 15:00:05 +00:00
|
|
|
.check_preempt_curr = check_preempt_wakeup,
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2019-11-08 13:15:58 +00:00
|
|
|
.pick_next_task = __pick_next_task_fair,
|
2007-07-09 16:51:58 +00:00
|
|
|
.put_prev_task = put_prev_task_fair,
|
2019-05-29 20:36:41 +00:00
|
|
|
.set_next_task = set_next_task_fair,
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2007-10-24 16:23:51 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2019-11-08 10:11:52 +00:00
|
|
|
.balance = balance_fair,
|
2008-10-22 07:25:26 +00:00
|
|
|
.select_task_rq = select_task_rq_fair,
|
2012-10-04 11:18:30 +00:00
|
|
|
.migrate_task_rq = migrate_task_rq_fair,
|
2013-06-26 05:05:39 +00:00
|
|
|
|
2009-11-30 11:16:46 +00:00
|
|
|
.rq_online = rq_online_fair,
|
|
|
|
.rq_offline = rq_offline_fair,
|
sched: Remove the cfs_rq dependency from set_task_cpu()
In order to remove the cfs_rq dependency from set_task_cpu() we
need to ensure the task is cfs_rq invariant for all callsites.
The simple approach is to substract cfs_rq->min_vruntime from
se->vruntime on dequeue, and add cfs_rq->min_vruntime on
enqueue.
However, this has the downside of breaking FAIR_SLEEPERS since
we loose the old vruntime as we only maintain the relative
position.
To solve this, we observe that we only migrate runnable tasks,
we do this using deactivate_task(.sleep=0) and
activate_task(.wakeup=0), therefore we can restrain the
min_vruntime invariance to that state.
The only other case is wakeup balancing, since we want to
maintain the old vruntime we cannot make it relative on dequeue,
but since we don't migrate inactive tasks, we can do so right
before we activate it again.
This is where we need the new pre-wakeup hook, we need to call
this while still holding the old rq->lock. We could fold it into
->select_task_rq(), but since that has multiple callsites and
would obfuscate the locking requirements, that seems like a
fudge.
This leaves the fork() case, simply make sure that ->task_fork()
leaves the ->vruntime in a relative state.
This covers all cases where set_task_cpu() gets called, and
ensures it sees a relative vruntime.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mike Galbraith <efault@gmx.de>
LKML-Reference: <20091216170518.191697025@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-12-16 17:04:41 +00:00
|
|
|
|
2015-07-15 00:04:40 +00:00
|
|
|
.task_dead = task_dead_fair,
|
2015-05-15 15:43:35 +00:00
|
|
|
.set_cpus_allowed = set_cpus_allowed_common,
|
2007-10-24 16:23:51 +00:00
|
|
|
#endif
|
2007-07-09 16:51:58 +00:00
|
|
|
|
|
|
|
.task_tick = task_tick_fair,
|
2009-11-27 16:32:46 +00:00
|
|
|
.task_fork = task_fork_fair,
|
2008-01-25 20:08:22 +00:00
|
|
|
|
|
|
|
.prio_changed = prio_changed_fair,
|
2011-01-17 16:03:27 +00:00
|
|
|
.switched_from = switched_from_fair,
|
2008-01-25 20:08:22 +00:00
|
|
|
.switched_to = switched_to_fair,
|
2008-02-29 20:21:01 +00:00
|
|
|
|
2009-09-21 01:31:53 +00:00
|
|
|
.get_rr_interval = get_rr_interval_fair,
|
|
|
|
|
sched/cputime: Fix clock_nanosleep()/clock_gettime() inconsistency
Commit d670ec13178d0 "posix-cpu-timers: Cure SMP wobbles" fixes one glibc
test case in cost of breaking another one. After that commit, calling
clock_nanosleep(TIMER_ABSTIME, X) and then clock_gettime(&Y) can result
of Y time being smaller than X time.
Reproducer/tester can be found further below, it can be compiled and ran by:
gcc -o tst-cpuclock2 tst-cpuclock2.c -pthread
while ./tst-cpuclock2 ; do : ; done
This reproducer, when running on a buggy kernel, will complain
about "clock_gettime difference too small".
Issue happens because on start in thread_group_cputimer() we initialize
sum_exec_runtime of cputimer with threads runtime not yet accounted and
then add the threads runtime to running cputimer again on scheduler
tick, making it's sum_exec_runtime bigger than actual threads runtime.
KOSAKI Motohiro posted a fix for this problem, but that patch was never
applied: https://lkml.org/lkml/2013/5/26/191 .
This patch takes different approach to cure the problem. It calls
update_curr() when cputimer starts, that assure we will have updated
stats of running threads and on the next schedule tick we will account
only the runtime that elapsed from cputimer start. That also assure we
have consistent state between cpu times of individual threads and cpu
time of the process consisted by those threads.
Full reproducer (tst-cpuclock2.c):
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/syscall.h>
#include <stdio.h>
#include <time.h>
#include <pthread.h>
#include <stdint.h>
#include <inttypes.h>
/* Parameters for the Linux kernel ABI for CPU clocks. */
#define CPUCLOCK_SCHED 2
#define MAKE_PROCESS_CPUCLOCK(pid, clock) \
((~(clockid_t) (pid) << 3) | (clockid_t) (clock))
static pthread_barrier_t barrier;
/* Help advance the clock. */
static void *chew_cpu(void *arg)
{
pthread_barrier_wait(&barrier);
while (1) ;
return NULL;
}
/* Don't use the glibc wrapper. */
static int do_nanosleep(int flags, const struct timespec *req)
{
clockid_t clock_id = MAKE_PROCESS_CPUCLOCK(0, CPUCLOCK_SCHED);
return syscall(SYS_clock_nanosleep, clock_id, flags, req, NULL);
}
static int64_t tsdiff(const struct timespec *before, const struct timespec *after)
{
int64_t before_i = before->tv_sec * 1000000000ULL + before->tv_nsec;
int64_t after_i = after->tv_sec * 1000000000ULL + after->tv_nsec;
return after_i - before_i;
}
int main(void)
{
int result = 0;
pthread_t th;
pthread_barrier_init(&barrier, NULL, 2);
if (pthread_create(&th, NULL, chew_cpu, NULL) != 0) {
perror("pthread_create");
return 1;
}
pthread_barrier_wait(&barrier);
/* The test. */
struct timespec before, after, sleeptimeabs;
int64_t sleepdiff, diffabs;
const struct timespec sleeptime = {.tv_sec = 0,.tv_nsec = 100000000 };
/* The relative nanosleep. Not sure why this is needed, but its presence
seems to make it easier to reproduce the problem. */
if (do_nanosleep(0, &sleeptime) != 0) {
perror("clock_nanosleep");
return 1;
}
/* Get the current time. */
if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &before) < 0) {
perror("clock_gettime[2]");
return 1;
}
/* Compute the absolute sleep time based on the current time. */
uint64_t nsec = before.tv_nsec + sleeptime.tv_nsec;
sleeptimeabs.tv_sec = before.tv_sec + nsec / 1000000000;
sleeptimeabs.tv_nsec = nsec % 1000000000;
/* Sleep for the computed time. */
if (do_nanosleep(TIMER_ABSTIME, &sleeptimeabs) != 0) {
perror("absolute clock_nanosleep");
return 1;
}
/* Get the time after the sleep. */
if (clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &after) < 0) {
perror("clock_gettime[3]");
return 1;
}
/* The time after sleep should always be equal to or after the absolute sleep
time passed to clock_nanosleep. */
sleepdiff = tsdiff(&sleeptimeabs, &after);
if (sleepdiff < 0) {
printf("absolute clock_nanosleep woke too early: %" PRId64 "\n", sleepdiff);
result = 1;
printf("Before %llu.%09llu\n", before.tv_sec, before.tv_nsec);
printf("After %llu.%09llu\n", after.tv_sec, after.tv_nsec);
printf("Sleep %llu.%09llu\n", sleeptimeabs.tv_sec, sleeptimeabs.tv_nsec);
}
/* The difference between the timestamps taken before and after the
clock_nanosleep call should be equal to or more than the duration of the
sleep. */
diffabs = tsdiff(&before, &after);
if (diffabs < sleeptime.tv_nsec) {
printf("clock_gettime difference too small: %" PRId64 "\n", diffabs);
result = 1;
}
pthread_cancel(th);
return result;
}
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20141112155843.GA24803@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-11-12 15:58:44 +00:00
|
|
|
.update_curr = update_curr_fair,
|
|
|
|
|
2008-02-29 20:21:01 +00:00
|
|
|
#ifdef CONFIG_FAIR_GROUP_SCHED
|
2016-06-17 11:38:55 +00:00
|
|
|
.task_change_group = task_change_group_fair,
|
2008-02-29 20:21:01 +00:00
|
|
|
#endif
|
2019-06-21 08:42:10 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_UCLAMP_TASK
|
|
|
|
.uclamp_enabled = 1,
|
|
|
|
#endif
|
2007-07-09 16:51:58 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
#ifdef CONFIG_SCHED_DEBUG
|
2011-10-25 08:00:11 +00:00
|
|
|
void print_cfs_stats(struct seq_file *m, int cpu)
|
2007-07-09 16:51:58 +00:00
|
|
|
{
|
2019-02-06 16:14:22 +00:00
|
|
|
struct cfs_rq *cfs_rq, *pos;
|
2007-07-09 16:51:58 +00:00
|
|
|
|
2008-01-25 20:08:34 +00:00
|
|
|
rcu_read_lock();
|
2019-02-06 16:14:22 +00:00
|
|
|
for_each_leaf_cfs_rq_safe(cpu_rq(cpu), cfs_rq, pos)
|
2007-08-09 09:16:47 +00:00
|
|
|
print_cfs_rq(m, cpu, cfs_rq);
|
2008-01-25 20:08:34 +00:00
|
|
|
rcu_read_unlock();
|
2007-07-09 16:51:58 +00:00
|
|
|
}
|
2015-06-25 17:21:43 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_NUMA_BALANCING
|
|
|
|
void show_numa_stats(struct task_struct *p, struct seq_file *m)
|
|
|
|
{
|
|
|
|
int node;
|
|
|
|
unsigned long tsf = 0, tpf = 0, gsf = 0, gpf = 0;
|
2019-07-16 15:20:47 +00:00
|
|
|
struct numa_group *ng;
|
2015-06-25 17:21:43 +00:00
|
|
|
|
2019-07-16 15:20:47 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
ng = rcu_dereference(p->numa_group);
|
2015-06-25 17:21:43 +00:00
|
|
|
for_each_online_node(node) {
|
|
|
|
if (p->numa_faults) {
|
|
|
|
tsf = p->numa_faults[task_faults_idx(NUMA_MEM, node, 0)];
|
|
|
|
tpf = p->numa_faults[task_faults_idx(NUMA_MEM, node, 1)];
|
|
|
|
}
|
2019-07-16 15:20:47 +00:00
|
|
|
if (ng) {
|
|
|
|
gsf = ng->faults[task_faults_idx(NUMA_MEM, node, 0)],
|
|
|
|
gpf = ng->faults[task_faults_idx(NUMA_MEM, node, 1)];
|
2015-06-25 17:21:43 +00:00
|
|
|
}
|
|
|
|
print_numa_stats(m, node, tsf, tpf, gsf, gpf);
|
|
|
|
}
|
2019-07-16 15:20:47 +00:00
|
|
|
rcu_read_unlock();
|
2015-06-25 17:21:43 +00:00
|
|
|
}
|
|
|
|
#endif /* CONFIG_NUMA_BALANCING */
|
|
|
|
#endif /* CONFIG_SCHED_DEBUG */
|
2011-10-25 08:00:11 +00:00
|
|
|
|
|
|
|
__init void init_sched_fair_class(void)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
open_softirq(SCHED_SOFTIRQ, run_rebalance_domains);
|
|
|
|
|
2011-08-10 21:21:01 +00:00
|
|
|
#ifdef CONFIG_NO_HZ_COMMON
|
2012-03-07 22:44:26 +00:00
|
|
|
nohz.next_balance = jiffies;
|
2018-02-13 10:31:17 +00:00
|
|
|
nohz.next_blocked = jiffies;
|
2011-10-25 08:00:11 +00:00
|
|
|
zalloc_cpumask_var(&nohz.idle_cpus_mask, GFP_NOWAIT);
|
|
|
|
#endif
|
|
|
|
#endif /* SMP */
|
|
|
|
|
|
|
|
}
|
2019-06-04 11:14:55 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Helper functions to facilitate extracting info from tracepoints.
|
|
|
|
*/
|
|
|
|
|
|
|
|
const struct sched_avg *sched_trace_cfs_rq_avg(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
return cfs_rq ? &cfs_rq->avg : NULL;
|
|
|
|
#else
|
|
|
|
return NULL;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(sched_trace_cfs_rq_avg);
|
|
|
|
|
|
|
|
char *sched_trace_cfs_rq_path(struct cfs_rq *cfs_rq, char *str, int len)
|
|
|
|
{
|
|
|
|
if (!cfs_rq) {
|
|
|
|
if (str)
|
|
|
|
strlcpy(str, "(null)", len);
|
|
|
|
else
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
cfs_rq_tg_path(cfs_rq, str, len);
|
|
|
|
return str;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(sched_trace_cfs_rq_path);
|
|
|
|
|
|
|
|
int sched_trace_cfs_rq_cpu(struct cfs_rq *cfs_rq)
|
|
|
|
{
|
|
|
|
return cfs_rq ? cpu_of(rq_of(cfs_rq)) : -1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(sched_trace_cfs_rq_cpu);
|
|
|
|
|
|
|
|
const struct sched_avg *sched_trace_rq_avg_rt(struct rq *rq)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
return rq ? &rq->avg_rt : NULL;
|
|
|
|
#else
|
|
|
|
return NULL;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(sched_trace_rq_avg_rt);
|
|
|
|
|
|
|
|
const struct sched_avg *sched_trace_rq_avg_dl(struct rq *rq)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
return rq ? &rq->avg_dl : NULL;
|
|
|
|
#else
|
|
|
|
return NULL;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(sched_trace_rq_avg_dl);
|
|
|
|
|
|
|
|
const struct sched_avg *sched_trace_rq_avg_irq(struct rq *rq)
|
|
|
|
{
|
|
|
|
#if defined(CONFIG_SMP) && defined(CONFIG_HAVE_SCHED_AVG_IRQ)
|
|
|
|
return rq ? &rq->avg_irq : NULL;
|
|
|
|
#else
|
|
|
|
return NULL;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(sched_trace_rq_avg_irq);
|
|
|
|
|
|
|
|
int sched_trace_rq_cpu(struct rq *rq)
|
|
|
|
{
|
|
|
|
return rq ? cpu_of(rq) : -1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(sched_trace_rq_cpu);
|
|
|
|
|
|
|
|
const struct cpumask *sched_trace_rd_span(struct root_domain *rd)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_SMP
|
|
|
|
return rd ? rd->span : NULL;
|
|
|
|
#else
|
|
|
|
return NULL;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(sched_trace_rd_span);
|