Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <1649245580-27256-1-git-send-email-zgpeng@tencent.com>
 <CAKfTPtDCXP8pt=F563sovxXJr-ALFuxNtE+1gWL-s7A-h4waew@mail.gmail.com> <CAE5vP3nYKKxfFWLG_idezXRiDALmGvN8EY0sL8vLK+5rnwMUaA@mail.gmail.com>
In-Reply-To: <CAE5vP3nYKKxfFWLG_idezXRiDALmGvN8EY0sL8vLK+5rnwMUaA@mail.gmail.com>
From:   Vincent Guittot <vincent.guittot@linaro.org>
Date:   Fri, 8 Apr 2022 09:39:25 +0200
Message-ID: <CAKfTPtAOvOa1MYqcnGgVo=C+cE5AAsDVyAiX1EgKhW5YGVSdBg@mail.gmail.com>
Subject: Re: [PATCH] sched/fair: Simplify the scene where both local and
 busiest are group_fully_busy
To:     =?UTF-8?B?5b2t5b+X5Yia?= <zgpeng.linux@gmail.com>
Cc:     mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        rostedt@goodmis.org, Benjamin Segall <bsegall@google.com>,
        mgorman@suse.de, bristot@redhat.com, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, 7 Apr 2022 at 04:38, =E5=BD=AD=E5=BF=97=E5=88=9A <zgpeng.linux@gmai=
l.com> wrote:
>
> When the type of the local group is group_has_spare, it does not affect i=
t, and it also has the opportunity
>
> to pull the process to the local cpu.
>

My point is :

local group is group_fully_busy
busiest group is group_fully_busy

but

local cpu is idle or newly idle otherwise we would have already returned

Currently, calculate_imbalance returns imbalance=3D0 because it is based
on avg_load which is not set for busiest group. Instead of skipping
calculate_imbalance, we might compute an imbalance similarly to what
is done for spare_capacity because local cpu being idle is an
opportunity to run something else

>
>
> This patch deals with scenarios where both the local group and the busies=
t group type are group_fully_busy.
>
> In this scenario, because the avg_load of the group of type group_fully_b=
usy is not calculated, this value is 0.
>
> Therefore, the condition of local->avg_load >=3D busiest->avg_load in cal=
culate_imbalance is satisfied, so the
>
> imbalance will be set to 0; Therefore, in this scenario, the original log=
ic has no chance to pull the process to
>
> the local cpu for execution.  I think it can be judged at the upper level=
, and there is no need to go into
>
> calculate_imbalance to do some useless work.
>
>
> Vincent Guittot <vincent.guittot@linaro.org> =E4=BA=8E2022=E5=B9=B44=E6=
=9C=886=E6=97=A5=E5=91=A8=E4=B8=89 23:41=E5=86=99=E9=81=93=EF=BC=9A
>>
>> On Wed, 6 Apr 2022 at 13:46, zgpeng <zgpeng.linux@gmail.com> wrote:
>> >
>> > When both local and busiest group are group_fully_busy type, because
>> > the avg_load of the group of type group_fully_busy is not calculated, =
the
>> > avg_load value is equal to 0. In this case, load balancing will not ac=
tually
>> > done, because after a series of calculations in the calculate_imbalanc=
e, it
>> > will be considered that load balance is not required. Therefore,it is =
not
>> > necessary to enter calculate_imbalance to do some useless work.
>> >
>> > Signed-off-by: zgpeng <zgpeng@tencent.com>
>> > Reviewed-by: Samuel Liao <samuelliao@tencent.com>
>> > ---
>> >  kernel/sched/fair.c | 12 ++++++++++++
>> >  1 file changed, 12 insertions(+)
>> >
>> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> > index 9f75303..cc1d6c4 100644
>> > --- a/kernel/sched/fair.c
>> > +++ b/kernel/sched/fair.c
>> > @@ -9634,6 +9634,18 @@ static struct sched_group *find_busiest_group(s=
truct lb_env *env)
>> >                          * busiest doesn't have any tasks waiting to r=
un
>> >                          */
>> >                         goto out_balanced;
>> > +
>>
>> We are there because both local and busiest are not overloaded, local
>> is idle or newly_idle and there might be an opportunity to pull a
>> waiting task on local to use this local cpu. I wonder if we should not
>> cover this opportunity in calculate_imbalance instead of skipping it
>>
>> > +               if (local->group_type =3D=3D group_fully_busy)
>> > +                       /*
>> > +                        * If local group is group_fully_busy, the cod=
e goes here,
>> > +                        * the type of busiest group must also be grou=
p_fully_busy.
>> > +                        * Because the avg_load of the group_fully_bus=
y type is not
>> > +                        * calculated at present, it is actually equal=
 to 0. In this
>> > +                        * scenario, load balance is not performed. th=
erefore, it can
>> > +                        * be returned directly here, and there is no =
need to do some
>> > +                        * useless work in calculate_imbalance.
>> > +                        */
>> > +                       goto out_balanced;
>> >         }
>> >
>> >  force_balance:
>> > --
>> > 2.9.5
>> >