All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Don <joshdon@google.com>
To: Chuyi Zhou <zhouchuyi@bytedance.com>
Cc: peterz@infradead.org, juri.lelli@redhat.com, mingo@redhat.com,
	vincent.guittot@linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/fair: favor non-idle group in tick preemption
Date: Thu, 27 Oct 2022 16:34:11 -0700	[thread overview]
Message-ID: <CABk29NtDny9qKZbZZ_i8Brwjtqs5GA0G4_SffzK4HzG3RrXVhQ@mail.gmail.com> (raw)
In-Reply-To: <20221027081630.34081-1-zhouchuyi@bytedance.com>

Hi Chuyi,

On Thu, Oct 27, 2022 at 1:16 AM Chuyi Zhou <zhouchuyi@bytedance.com> wrote:
>
> The non-idle se dominates competition vs the idle se when they
> are belong to the same group. We ensure that idle groups would not
> preempt non-idle group in wakeup preemption(see check_preempt_wakeup()).
> However, this can happen in tick preemption, since check_preempt_tick()
> dose not check current/se is idle or not. This patch adds this check.
>
> Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com>
> ---
>  kernel/sched/fair.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index e4a0b8bd941c..f3324b8753b3 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4750,6 +4750,7 @@ static void
>  check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
>  {
>         unsigned long ideal_runtime, delta_exec;
> +       int cse_is_idle, pse_is_idle;
>         struct sched_entity *se;
>         s64 delta;
>
> @@ -4779,8 +4780,17 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
>         if (delta < 0)
>                 return;
>
> -       if (delta > ideal_runtime)
> +       if (delta > ideal_runtime) {
> +               /*
> +                * Favor non-idle group even in tick preemption
> +                */
> +               cse_is_idle = se_is_idle(curr);
> +               pse_is_idle = se_is_idle(se);
> +               if (unlikely(!cse_is_idle && pse_is_idle))
> +                       return;

This would make it so that we never have tick based preemption of a
non-idle entity by an idle entity. That's a recipe for starvation of
the idle entity, if the non-idle entity is cpu bound.

Beyond that though, I'm not quite sure the issue being solved here.
The large difference in weight between the idle and non-idle entity
means that the non-idle entity will not be preempted for quite a while
due to its ideal_runtime being quite high. The idle entity will
quickly be preempted on the next tick it takes due to the smaller
value of sysctl_sched_idle_min_granularity.

The wakeup check is useful for latency sensitive non-idle tasks.
However, in steady state competition between idle and non-idle, we
must allow some amount of round-robin.

> +
>                 resched_curr(rq_of(cfs_rq));
> +       }
>  }
>
>  static void
> --
> 2.20.1
>

Best,
Josh

  reply	other threads:[~2022-10-27 23:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27  8:16 [PATCH] sched/fair: favor non-idle group in tick preemption Chuyi Zhou
2022-10-27 23:34 ` Josh Don [this message]
2022-10-28  3:57   ` Chuyi Zhou
2022-10-28 22:40     ` Josh Don
2022-10-31  8:39       ` Chuyi Zhou
2022-10-31 22:44         ` Josh Don
2022-11-01  3:45           ` Chuyi Zhou
2022-11-01 23:39             ` Josh Don
2022-11-03 11:24               ` Chuyi Zhou
2022-11-04  3:49               ` [External] " Hao Jia
2022-11-04 21:25                 ` Josh Don
2022-11-11  3:50               ` Abel Wu
2022-11-11 19:14                 ` Josh Don
2022-11-01  9:14           ` Abel Wu

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=CABk29NtDny9qKZbZZ_i8Brwjtqs5GA0G4_SffzK4HzG3RrXVhQ@mail.gmail.com \
    --to=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=vincent.guittot@linaro.org \
    --cc=zhouchuyi@bytedance.com \
    /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.