mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chengming Zhou <zhouchengming@bytedance.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	mingo@redhat.com, peterz@infradead.org, rostedt@goodmis.org,
	bsegall@google.com, vschneid@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [External] Re: [PATCH v2 07/10] sched/fair: use update_load_avg() to attach/detach entity load_avg
Date: Thu, 21 Jul 2022 21:56:05 +0800	[thread overview]
Message-ID: <3cc8def4-54ef-9ca5-7da9-eaa38ad9bd4c@bytedance.com> (raw)
In-Reply-To: <CAKfTPtBo9GgkT1VeVA+1CBhiVZ8Vf+kp0XV3PWcBLGuZaz_hKQ@mail.gmail.com>

On 2022/7/20 23:34, Vincent Guittot wrote:
> On Wed, 20 Jul 2022 at 15:41, Chengming Zhou
> <zhouchengming@bytedance.com> wrote:
>>
>> On 2022/7/19 18:29, Vincent Guittot wrote:
>>> On Fri, 15 Jul 2022 at 18:21, Chengming Zhou
>>> <zhouchengming@bytedance.com> wrote:
>>>>
> 
> ...
> 
>>>>
>>>>>
>>>>> Looks to me that you want to replace this by your `freeze PELT when
>>>>> outside fair` model.
>>>>
>>>> Yes, want to freeze PELT for two !fair cases:
>>>>
>>>> 1. !fair task hasn't been fair before: will still have its init load_avg
>>>>    when switch to fair.
>>>
>>> But I'm not sure it makes sense to keep these init values. As an
>>> example, the util_avg is set according to the cpu utilization at the
>>> time of the task creation. I would tend to decay them as these init
>>> values become less and less relevant.
>>>
>>> so we should return early in post_init_entity_util_avg() and don't set
>>> util_avg if sched class is not cfs
>>
>> Yes, this indeed is a problem if we attach this init sched_avg of !fair task.
>> I'm also not sure whether it make sense to keep them to 0 ? Will it cause
>> unfairness problem between cfs_rqs?
> 
> Why should it cause an unfairness problem ? !fair tasks are not
> accounted and their pelt values will be decayed down to 0 after 320ms
> anyway (with the current implementation). So it's just like if you
> started directly after those 320ms

Thanks for your patient explain. IMHO, I am thinking if we have init sched_avg
for new fair task (A), but have 0 for new task switched from !fair (B). Then
what's the point of init sched_avg for the fair task?

The B task will need some time to reach its stable load value, so in this process
its cfs_rq may can't get enough shares? Imaging below scenario, if we have fair
task A and switched from !fair task B at the same time, could cause unfairness
between cfs0 and cfs1 ?

CPU0   tg   CPU1
  |  /    \  |
  | /      \ |
cfs0        cfs1
 (A)         (B)

If runnable_avg and util_avg are 0 when switched from !fair, so we need more time
to do load balance or CPU frequency adjust? I think it's the reason why we have
init sched_avg for new fair task. Should we care about these, or it will be no problem?

I'm not sure, I must have missed something :-)

Thanks!

> 
>>
>>>
>>>>
>>>> 2. !fair task has been switched_from_fair(): will still keep its lastest
>>>>    load_avg when switch to fair.
>>>>
>>>>>
>>>>>> This patch make update_load_avg() the only location of attach/detach,
>>>>>> and can handle these corner cases like change cgroup of NEW tasks,
>>>>>> by checking last_update_time before attach/detach.
>>>>>
>>>>> [...]
>>>>>
>>>>>> @@ -11527,9 +11522,7 @@ static void detach_entity_cfs_rq(struct sched_entity *se)
>>>>>>      struct cfs_rq *cfs_rq = cfs_rq_of(se);
>>>>>>
>>>>>>      /* Catch up with the cfs_rq and remove our load when we leave */
>>>>>> -    update_load_avg(cfs_rq, se, 0);
>>>>>> -    detach_entity_load_avg(cfs_rq, se);
>>>>>> -    update_tg_load_avg(cfs_rq);
>>>>>> +    update_load_avg(cfs_rq, se, UPDATE_TG | DO_DETACH);
>>>>>
>>>>> IMHO, the DO_[DE|AT]TACH comments in update_load_avg() would have to be
>>>>> updated in this case.
>>>>
>>>> Correct, will do.
>>>>
>>>> Thanks.
>>>>
>>>>>
>>>>> [...]

  reply	other threads:[~2022-07-21 13:56 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-13  4:04 [PATCH v2 00/10] sched: task load tracking optimization and cleanup Chengming Zhou
2022-07-13  4:04 ` [PATCH v2 01/10] sched/fair: combine detach into dequeue when migrating task Chengming Zhou
2022-07-13  4:04 ` [PATCH v2 02/10] sched/fair: update comments in enqueue/dequeue_entity() Chengming Zhou
2022-07-13  4:04 ` [PATCH v2 03/10] sched/fair: maintain task se depth in set_task_rq() Chengming Zhou
2022-07-14 12:30   ` Dietmar Eggemann
2022-07-14 13:03     ` [External] " Chengming Zhou
2022-07-18  7:16   ` Vincent Guittot
2022-07-13  4:04 ` [PATCH v2 04/10] sched/fair: remove redundant cpu_cgrp_subsys->fork() Chengming Zhou
2022-07-14 12:31   ` Dietmar Eggemann
2022-07-14 13:06     ` [External] " Chengming Zhou
2022-07-13  4:04 ` [PATCH v2 05/10] sched/fair: reset sched_avg last_update_time before set_task_rq() Chengming Zhou
2022-07-14 12:31   ` Dietmar Eggemann
2022-07-19  8:49   ` Vincent Guittot
2022-07-13  4:04 ` [PATCH v2 06/10] sched/fair: delete superfluous SKIP_AGE_LOAD Chengming Zhou
2022-07-14 12:33   ` Dietmar Eggemann
2022-07-14 13:24     ` [External] " Chengming Zhou
2022-07-13  4:04 ` [PATCH v2 07/10] sched/fair: use update_load_avg() to attach/detach entity load_avg Chengming Zhou
2022-07-15 11:18   ` Dietmar Eggemann
2022-07-15 16:21     ` [External] " Chengming Zhou
2022-07-19 10:29       ` Vincent Guittot
2022-07-20 13:40         ` Chengming Zhou
2022-07-20 15:34           ` Vincent Guittot
2022-07-21 13:56             ` Chengming Zhou [this message]
2022-07-21 14:13               ` Vincent Guittot
2022-07-19 15:02       ` Dietmar Eggemann
2022-07-20 13:43         ` Chengming Zhou
2022-07-13  4:04 ` [PATCH v2 08/10] sched/fair: fix load tracking for new forked !fair task Chengming Zhou
2022-07-19 12:35   ` Vincent Guittot
2022-07-20 13:48     ` [External] " Chengming Zhou
2022-07-13  4:04 ` [PATCH v2 09/10] sched/fair: stop load tracking when task switched_from_fair() Chengming Zhou
2022-07-14 12:33   ` Dietmar Eggemann
2022-07-14 13:43     ` [External] " Chengming Zhou
2022-07-15 11:15       ` Dietmar Eggemann
2022-07-15 16:35         ` Chengming Zhou
2022-07-19 13:20   ` Vincent Guittot
2022-07-27 10:55     ` Chengming Zhou
2022-07-13  4:04 ` [PATCH v2 10/10] sched/fair: delete superfluous set_task_rq_fair() Chengming Zhou

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=3cc8def4-54ef-9ca5-7da9-eaa38ad9bd4c@bytedance.com \
    --to=zhouchengming@bytedance.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®