All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Zhang Qiao <zhangqiao22@huawei.com>,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	peterz@infradead.org, juri.lelli@redhat.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, bristot@redhat.com,
	vschneid@redhat.com
Subject: Re: [PATCH v2] sched/fair: sanitize vruntime of entity being migrated
Date: Mon, 20 Mar 2023 14:26:35 +0100	[thread overview]
Message-ID: <CAKfTPtADr6ds6kmfE73J-33fT6mkziGZ4=x45rpwmGhv-u1f2A@mail.gmail.com> (raw)
In-Reply-To: <df2cccda-1550-b06b-aa74-e0f054e9fb9d@arm.com>

On Mon, 20 Mar 2023 at 13:29, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote:
>
> On 18/03/2023 08:45, Zhang Qiao wrote:
> >
> >
> > 在 2023/3/18 0:08, Vincent Guittot 写道:
> >> Commit 829c1651e9c4 ("sched/fair: sanitize vruntime of entity being placed")
> >> fixes an overflowing bug, but ignore a case that se->exec_start is reset
> >> after a migration.
> >>
> >> For fixing this case, we delay the reset of se->exec_start after
> >> placing the entity which se->exec_start to detect long sleeping task.
> >>
> >> In order to take into account a possible divergence between the clock_task
> >> of 2 rqs, we increase the threshold to around 104 days.
> >>
> >>
> >> Fixes: 829c1651e9c4 ("sched/fair: sanitize vruntime of entity being placed")
> >> Signed-off-by: Zhang Qiao <zhangqiao22@huawei.com>
> >> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> >> ---
> >>
> >> My last proposal was not yet correct as the exec_start was not always
> >> reset after migrating a task. I finally found this solution which keeps
> >> the long sleep detection to one place as well as the reset of se->exec_start.
> >>
> >
> > Tested-by: Zhang Qiao <zhangqiao22@huawei.com>
> >
> > I have retested it with this version, and the result is fine.
> >
> > -------
> >
> >  Performance counter stats for 'hackbench -g 44 -f 20 --process --pipe -l 60000 -s 100' (10 runs):
> >
> >              80.10 +- 1.22 seconds time elapsed  ( +-  1.53% )
>
> [...]
>
> >> @@ -8701,7 +8734,7 @@ static void attach_task(struct rq *rq, struct task_struct *p)
> >>      lockdep_assert_rq_held(rq);
> >>
> >>      WARN_ON_ONCE(task_rq(p) != rq);
> >> -    activate_task(rq, p, ENQUEUE_NOCLOCK);
> >> +    activate_task(rq, p, ENQUEUE_NOCLOCK | ENQUEUE_MIGRATED);
> >>      check_preempt_curr(rq, p, 0);
>
> Why not:
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index b9bc1ab67aaa..96dd3a62e683 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7674,7 +7674,10 @@ static void migrate_task_rq_fair(struct task_struct *p, int new_cpu)
>                 se->vruntime -= u64_u32_load(cfs_rq->min_vruntime);
>         }
>
> -       if (!task_on_rq_migrating(p)) {
> +       if (task_on_rq_migrating(p)) {
> +               /* We have migrated, no longer consider this task hot */
> +               se->exec_start = 0;

mainly to keep the clear of se->exec_start = 0 in one place to ease
the maintenance


> +       } else {
>                 remove_entity_load_avg(se);
>
>                 /*
> @@ -8726,7 +8729,7 @@ static void attach_task(struct rq *rq, struct task_struct *p)
>         lockdep_assert_rq_held(rq);
>
>         WARN_ON_ONCE(task_rq(p) != rq);
> -       activate_task(rq, p, ENQUEUE_NOCLOCK | ENQUEUE_MIGRATED);
> +       activate_task(rq, p, ENQUEUE_NOCLOCK);
>         check_preempt_curr(rq, p, 0);
>  }
>
>
> entity_is_long_sleeper() will bail early for these rq-migrating tasks
> for which a long-sleep test would make little sense anyway.
>
> Plus move_queued_task() (e.g. from sched_exex()) would be covered as well.

  reply	other threads:[~2023-03-20 13:27 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17 16:08 [PATCH v2] sched/fair: sanitize vruntime of entity being migrated Vincent Guittot
2023-03-18  7:45 ` Zhang Qiao
2023-03-20 12:29   ` Dietmar Eggemann
2023-03-20 13:26     ` Vincent Guittot [this message]
2023-03-21 10:02 ` Peter Zijlstra
2023-03-21 10:29   ` Dietmar Eggemann
2023-03-21 10:49     ` Peter Zijlstra
2023-03-21 11:12       ` Vincent Guittot
2023-03-21 11:13       ` Dietmar Eggemann
2023-03-21 12:26         ` Peter Zijlstra
2023-03-21 12:28 ` Peter Zijlstra
2023-03-21 12:38   ` Vincent Guittot
2023-03-22  9:07 ` [tip: sched/urgent] sched/fair: Sanitize " tip-bot2 for Vincent Guittot
2023-03-24  4:05 ` [PATCH v2] sched/fair: sanitize " Chen Yu
  -- strict thread matches above, loose matches on Subject: below --
2023-03-06 13:24 Zhang Qiao
2023-03-06 13:53 ` Vincent Guittot
2023-03-07 10:26   ` Vincent Guittot
2023-03-07 11:05     ` Zhang Qiao
2023-03-07 13:41     ` Zhang Qiao
2023-03-08  8:01       ` Vincent Guittot
2023-03-08 12:55         ` Vincent Guittot
2023-03-09  8:37           ` Zhang Qiao
2023-03-09  9:09             ` Dietmar Eggemann
2023-03-09  9:30               ` Zhang Qiao
2023-03-09 10:48             ` Vincent Guittot
2023-03-09 14:23               ` Zhang Qiao
2023-03-07  2:16 ` kernel test robot
2023-03-07 12:45 ` Dietmar Eggemann
2023-03-07 14:06   ` Zhang Qiao
2023-03-09  9:43   ` Zhang Qiao
2023-03-08 14:33 ` Chen Yu
2023-03-09 13:05 ` Peter Zijlstra
2023-03-09 13:34   ` Vincent Guittot
2023-03-09 14:28     ` Peter Zijlstra
2023-03-09 14:36       ` Peter Zijlstra
2023-03-09 15:14         ` Vincent Guittot
2023-03-10 14:29           ` Vincent Guittot
2023-03-11  9:57             ` Zhang Qiao
2023-03-13 14:23               ` Vincent Guittot
2023-03-14 11:03                 ` Zhang Qiao
2023-03-14 13:26                   ` Vincent Guittot
2023-03-14 13:38                     ` Zhang Qiao
2023-03-14 13:39                       ` Vincent Guittot
2023-03-14 15:32                         ` Vincent Guittot
2023-03-15  9:16                           ` Zhang Qiao
2023-03-15 15:30                             ` Vincent Guittot
2023-03-13  9:06             ` Dietmar Eggemann
2023-03-13 18:17               ` Dietmar Eggemann
2023-03-14  7:41                 ` Vincent Guittot
2023-03-14 12:07                   ` Peter Zijlstra
2023-03-14 13:24                     ` Vincent Guittot
2023-03-14 17:16                       ` Peter Zijlstra
2023-03-15  7:18                         ` Vincent Guittot
2023-03-15  8:42                           ` Vincent Guittot
2023-03-15 10:15                             ` Dietmar Eggemann
2023-03-15 10:21                               ` Vincent Guittot
2023-03-15 13:35                                 ` Dietmar Eggemann
2023-03-15 15:32                                   ` Vincent Guittot
2023-03-14 13:29                     ` Dietmar Eggemann
2023-03-14 13:37                       ` Dietmar Eggemann

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='CAKfTPtADr6ds6kmfE73J-33fT6mkziGZ4=x45rpwmGhv-u1f2A@mail.gmail.com' \
    --to=vincent.guittot@linaro.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vschneid@redhat.com \
    --cc=zhangqiao22@huawei.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.