All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: linux-kernel@vger.kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Qais Yousef <qais.yousef@arm.com>,
	Quentin Perret <qperret@google.com>,
	Pavan Kondeti <pkondeti@codeaurora.org>,
	Rik van Riel <riel@surriel.com>,
	Lingutla Chandrasekhar <clingutla@codeaurora.org>
Subject: [PATCH v5 0/3] sched/fair: load-balance vs capacity margins
Date: Wed,  7 Apr 2021 23:06:25 +0100	[thread overview]
Message-ID: <20210407220628.3798191-1-valentin.schneider@arm.com> (raw)

Hi folks,

I split up the extra misfit patches from v3 as I'm still playing around with
those following Vincent's comments. In the meantime, I believe the first few
patches of the series can still be considered as standalone.

o Patch 1 prevents pcpu kworkers from causing group_imbalanced
o Patch 2 is an independent active balance cleanup
o Patch 3 introduces yet another margin for capacity to capacity
  comparisons

The "important" one is patch 3, as it solves misfit migration issues on newer
platforms.
  
This is based on top of today's tip/sched/core at:

  0a2b65c03e9b ("sched/topology: Remove redundant cpumask_and() in init_overlap_sched_group()")

Testing
=======

I ran my usual [1] misfit tests on
o TC2
o Juno
o HiKey960
o Dragonboard845C
o RB5

RB5 has a similar topology to Pixel4 and highlights the problem of having
two different CPU capacity values above 819 (in this case 871 and 1024):
without these patches, CPU hogs (i.e. misfit tasks) running on the "medium"
CPUs will never be upmigrated to a "big" via misfit balance.


The 0day bot reported [3] the first patch causes a ~14% regression on its
stress-ng.vm-segv testcase. I ran that testcase on: 

o Ampere eMAG (arm64, 32 cores)
o 2-socket Xeon E5-2690 (x86, 40 cores)

and found at worse a -0.3% regression and at best a 2% improvement - I'm
getting nowhere near -14%.
  
Revisions
=========

v4 -> v5
--------
o Collected Reviewed-by (Vincent, Dietmar)
o Fixed typo in patch 1 (Dietmar)
o Appended paragraph about using local group vs dst cpu in patch 3 (Dietmar)

v3 -> v4
--------
o Tore out the extra misfit patches

o Rewrote patch 1 changelog (Dietmar)
o Reused LBF_ACTIVE_BALANCE to ditch LBF_DST_PINNED active balance logic
  (Dietmar)
o Collected Tested-by (Lingutla)  

o Squashed capacity_greater() introduction and use (Vincent)
o Removed sched_asym_cpucapacity() static key proliferation (Vincent)

v2 -> v3
--------

o Rebased on top of latest tip/sched/core
o Added test results vs stress-ng.vm-segv

v1 -> v2
--------

o Collected Reviewed-by
o Minor comment and code cleanups

o Consolidated static key vs SD flag explanation (Dietmar)

  Note to Vincent: I didn't measure the impact of adding said static key to
  load_balance(); I do however believe it is a low hanging fruit. The
  wrapper keeps things neat and tidy, and is also helpful for documenting
  the intricacies of the static key status vs the presence of the SD flag
  in a CPU's sched_domain hierarchy.
  
o Removed v1 patch 4 - root_domain.max_cpu_capacity is absolutely not what
  I had convinced myself it was.
o Squashed capacity margin usage with removal of
  group_smaller_{min, max}_capacity() (Vincent)   
o Replaced v1 patch 7 with Lingutla's can_migrate_task() patch [2]
o Rewrote task_hot() modification changelog

Links
=====

[1]: https://lisa-linux-integrated-system-analysis.readthedocs.io/en/master/kernel_tests.html#lisa.tests.scheduler.misfit.StaggeredFinishes
[2]: http://lore.kernel.org/r/20210217120854.1280-1-clingutla@codeaurora.org
[3]: http://lore.kernel.org/r/20210223023004.GB25487@xsang-OptiPlex-9020

Cheers,
Valentin

Lingutla Chandrasekhar (1):
  sched/fair: Ignore percpu threads for imbalance pulls

Valentin Schneider (2):
  sched/fair: Clean up active balance nr_balance_failed trickery
  sched/fair: Introduce a CPU capacity comparison helper

 kernel/sched/fair.c | 68 +++++++++++++++++++--------------------------
 1 file changed, 29 insertions(+), 39 deletions(-)

--
2.25.1


             reply	other threads:[~2021-04-07 22:06 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-07 22:06 Valentin Schneider [this message]
2021-04-07 22:06 ` [PATCH v5 1/3] sched/fair: Ignore percpu threads for imbalance pulls Valentin Schneider
2021-04-09 11:24   ` [tip: sched/core] " tip-bot2 for Lingutla Chandrasekhar
2021-04-09 12:05   ` tip-bot2 for Lingutla Chandrasekhar
2021-04-09 16:14   ` tip-bot2 for Lingutla Chandrasekhar
2021-04-14  5:21   ` [sched/fair] 38ac256d1c: stress-ng.vm-segv.ops_per_sec -13.8% regression kernel test robot
2021-04-14  5:21     ` kernel test robot
2021-04-14 17:17     ` Valentin Schneider
2021-04-14 17:17       ` Valentin Schneider
2021-04-21  3:20       ` Oliver Sang
2021-04-21  3:20         ` Oliver Sang
2021-04-21 10:27         ` Valentin Schneider
2021-04-21 10:27           ` Valentin Schneider
2021-04-21 12:03           ` Peter Zijlstra
2021-04-21 12:03             ` Peter Zijlstra
2021-04-22  7:47           ` Oliver Sang
2021-04-22  7:47             ` Oliver Sang
2021-04-22  9:55             ` Valentin Schneider
2021-04-22  9:55               ` Valentin Schneider
2021-04-22 20:42               ` Valentin Schneider
2021-04-22 20:42                 ` Valentin Schneider
2021-04-28 22:00                 ` Valentin Schneider
2021-04-28 22:00                   ` Valentin Schneider
2021-05-06 16:11                   ` Valentin Schneider
2021-05-06 16:11                     ` Valentin Schneider
2021-04-07 22:06 ` [PATCH v5 2/3] sched/fair: Clean up active balance nr_balance_failed trickery Valentin Schneider
2021-04-09 11:24   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2021-04-09 12:05   ` tip-bot2 for Valentin Schneider
2021-04-09 16:14   ` tip-bot2 for Valentin Schneider
2021-04-07 22:06 ` [PATCH v5 3/3] sched/fair: Introduce a CPU capacity comparison helper Valentin Schneider
2021-04-09 11:24   ` [tip: sched/core] " tip-bot2 for Valentin Schneider
2021-04-09 12:05   ` tip-bot2 for Valentin Schneider
2021-04-09 16:14   ` tip-bot2 for Valentin Schneider

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210407220628.3798191-1-valentin.schneider@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=clingutla@codeaurora.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=pkondeti@codeaurora.org \
    --cc=qais.yousef@arm.com \
    --cc=qperret@google.com \
    --cc=riel@surriel.com \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.