All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: Yafang Shao <laoar.shao@gmail.com>,
	mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
	rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
	bristot@redhat.com
Cc: linux-kernel@vger.kernel.org, Yafang Shao <laoar.shao@gmail.com>
Subject: Re: [RFC PATCH 0/4] sched: Introduce cfs_migration
Date: Fri, 05 Nov 2021 17:00:22 +0000	[thread overview]
Message-ID: <87cznetu55.mognet@arm.com> (raw)
In-Reply-To: <20211104145713.4419-1-laoar.shao@gmail.com>


Hi,

On 04/11/21 14:57, Yafang Shao wrote:
> The active load balance has a known issue[1][2] that there is a race
> window between waking up the migration thread on the busiest CPU and it
> begins to preempt the current running CFS task. This race window may cause
> unexpected behavior that the current running CFS task may be preempted
> by a RT task first, and then the RT task will be preempted by this
> waked migration thread. Per our tracing, the latency caused by this
> preemption can be greater than 1ms, which is not a small latency for the
> RT tasks.
>
> We'd better set a proper priority to this balance work so that it can
> preempt CFS task only. A new per-cpu thread cfs_migration is introduced
> for this purpose. The cfs_migration thread has a priority FIFO-1,
> which means it can preempt any cfs tasks but can't preempt other FIFO
> tasks.
>
> Besides the active load balance work, the numa balance work also applies
> to CFS tasks only. So we'd better assign cfs_migraion to numa balance
> work as well.
>
> [1]. https://lore.kernel.org/lkml/CAKfTPtBygNcVewbb0GQOP5xxO96am3YeTZNP5dK9BxKHJJAL-g@mail.gmail.com/
> [2]. https://lore.kernel.org/lkml/20210615121551.31138-1-laoar.shao@gmail.com/
>

So overall I quite like the idea, but am not entirely convinced by the
implementation. See comments in rest of the thread - in any case, thanks
for taking a jab at that!

> Yafang Shao (4):
>   stop_machine: Move cpu_stop_done into stop_machine.h
>   sched/fair: Introduce cfs_migration
>   sched/fair: Do active load balance in cfs_migration
>   sched/core: Do numa balance in cfs_migration
>
>  include/linux/stop_machine.h |  12 +++
>  kernel/sched/core.c          |   2 +-
>  kernel/sched/fair.c          | 143 ++++++++++++++++++++++++++++++++++-
>  kernel/sched/sched.h         |   2 +
>  kernel/stop_machine.c        |  14 +---
>  5 files changed, 158 insertions(+), 15 deletions(-)
>
> --
> 2.17.1

      parent reply	other threads:[~2021-11-05 17:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 14:57 [RFC PATCH 0/4] sched: Introduce cfs_migration Yafang Shao
2021-11-04 14:57 ` [RFC PATCH 1/4] stop_machine: Move cpu_stop_done into stop_machine.h Yafang Shao
2021-11-05 17:00   ` Valentin Schneider
2021-11-06  7:30     ` Yafang Shao
2021-11-04 14:57 ` [RFC PATCH 2/4] sched/fair: Introduce cfs_migration Yafang Shao
2021-11-04 22:22   ` kernel test robot
2021-11-05  6:48     ` Yafang Shao
2021-11-04 22:22   ` [RFC PATCH] sched/fair: __pcpu_scope_cfs_migrater can be static kernel test robot
2021-11-05  6:45     ` Yafang Shao
2021-11-05 17:01   ` [RFC PATCH 2/4] sched/fair: Introduce cfs_migration Valentin Schneider
2021-11-06  7:40     ` Yafang Shao
2021-11-09 10:47       ` Valentin Schneider
2021-11-10 14:17         ` Yafang Shao
2021-11-07  9:38   ` [sched/fair] 64228563c2: WARNING:at_kernel/kthread.c:#__kthread_bind_mask kernel test robot
2021-11-07  9:38     ` kernel test robot
2021-11-08  3:53     ` Yafang Shao
2021-11-08  3:53       ` Yafang Shao
2021-11-04 14:57 ` [RFC PATCH 3/4] sched/fair: Do active load balance in cfs_migration Yafang Shao
2021-11-04 14:57 ` [RFC PATCH 4/4] sched/core: Do numa " Yafang Shao
2021-11-05 17:02   ` Valentin Schneider
2021-11-06  7:40     ` Yafang Shao
2021-11-05 17:00 ` Valentin Schneider [this message]

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=87cznetu55.mognet@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --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.