All of lore.kernel.org
 help / color / mirror / Atom feed
From: Abel Wu <wuyun.abel@bytedance.com>
To: Josh Don <joshdon@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Mel Gorman <mgorman@suse.de>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Abel Wu <wuyun.abel@bytedance.com>
Subject: Re: [RFC v2 2/2] sched/fair: introduce sched-idle balance
Date: Thu, 14 Apr 2022 23:38:06 +0800	[thread overview]
Message-ID: <60cbd089-f514-44eb-a629-62556936be35@bytedance.com> (raw)
In-Reply-To: <CABk29Nu9QTUKHP3cyx3qpiGcNM-PbaSxCvfhvBvOs++67KeXCw@mail.gmail.com>

On 4/14/22 8:08 AM, Josh Don Wrote:
>>>>    /*
>>>>     * Use locality-friendly rq->overloaded to cache the status of the rq
>>>>     * to minimize the heavy cost on LLC shared data.
>>>> @@ -7837,6 +7867,22 @@ int can_migrate_task(struct task_struct *p, struct lb_env *env)
>>>>           if (kthread_is_per_cpu(p))
>>>>                   return 0;
>>>>
>>>> +       if (unlikely(task_h_idle(p))) {
>>>> +               /*
>>>> +                * Disregard hierarchically idle tasks during sched-idle
>>>> +                * load balancing.
>>>> +                */
>>>> +               if (env->idle == CPU_SCHED_IDLE)
>>>> +                       return 0;
>>>> +       } else if (!static_branch_unlikely(&sched_asym_cpucapacity)) {
>>>> +               /*
>>>> +                * It's not gonna help if stacking non-idle tasks on one
>>>> +                * cpu while leaving some idle.
>>>> +                */
>>>> +               if (cfs_rq_busy(env->src_rq) && !need_pull_cfs_task(env->dst_rq))
>>>> +                       return 0;
>>>
>>> These checks don't involve the task at all, so this kind of check
>>> should be pushed into the more general load balance function. But, I'm
>>> not totally clear on the motivation here. If we have cpu A with 1
>>> non-idle task and 100 idle tasks, and cpu B with 1 non-idle task, we
>>> should definitely try to load balance some of the idle tasks from A to
>>> B. idle tasks _do_ get time to run (although little), and this can add
>>> up and cause antagonism to the non-idle task if there are a lot of
>>> idle threads.
>>
>> CPU_SCHED_IDLE means triggered by sched_idle_balance() in which pulls
>> a non-idle task for the unoccupied cpu from the overloaded ones, so
>> idle tasks are not the target and should be skipped.
>>
>> The second part is: if we have cpu A with 1 non-idle task and 100 idle
>> tasks, and B with >=1 non-idle task, we don't migrate the last non-idle
>> task on A to B.
> 
> It could be possible that we do want to migrate the last non-idle task
> from A to B, if the weight sum of idle tasks on A is very high (easily
> possible with affinity restrictions). So I think we should leave
> regular load balance alone here if it really wants to move the
> non-idle task, and wrap this entire block in an if (env->idle ==
> CPU_SCHED_IDLE).

Makes sense. I will fix it in next version.

Thanks & BR,
Abel


  reply	other threads:[~2022-04-14 16:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-09 13:51 [RFC v2 0/2] introduece sched-idle balance Abel Wu
2022-04-09 13:51 ` [RFC v2 1/2] sched/fair: filter out overloaded cpus in SIS Abel Wu
2022-04-12  1:23   ` Josh Don
2022-04-12 17:55     ` Abel Wu
2022-04-13 23:49       ` Josh Don
2022-04-14 15:36         ` Abel Wu
2022-04-15 23:21           ` Josh Don
2022-04-25  7:02   ` [sched/fair] 6b433275e3: stress-ng.sock.ops_per_sec 16.2% improvement kernel test robot
2022-04-25  7:02     ` kernel test robot
2022-04-09 13:51 ` [RFC v2 2/2] sched/fair: introduce sched-idle balance Abel Wu
2022-04-12  1:59   ` Josh Don
2022-04-12 17:56     ` Abel Wu
2022-04-14  0:08       ` Josh Don
2022-04-14 15:38         ` Abel Wu [this message]
2022-04-27 13:15   ` [sched/fair] ae44f2177f: reaim.jobs_per_min 2.3% improvement kernel test robot
2022-04-27 13:15     ` kernel test robot

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=60cbd089-f514-44eb-a629-62556936be35@bytedance.com \
    --to=wuyun.abel@bytedance.com \
    --cc=joshdon@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=peterz@infradead.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.