Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <bc879bcb34f089e5888f6721aa2365f0832b69da.camel@surriel.com>
Subject: Re: [PATCH v3 09/10] sched/fair: use load instead of runnable load
 in wakeup path
From:   Rik van Riel <riel@surriel.com>
To:     Vincent Guittot <vincent.guittot@linaro.org>,
        linux-kernel@vger.kernel.org, mingo@redhat.com,
        peterz@infradead.org
Cc:     pauld@redhat.com, valentin.schneider@arm.com,
        srikar@linux.vnet.ibm.com, quentin.perret@arm.com,
        dietmar.eggemann@arm.com, Morten.Rasmussen@arm.com,
        hdanton@sina.com
Date:   Mon, 07 Oct 2019 11:14:05 -0400
In-Reply-To: <1568878421-12301-10-git-send-email-vincent.guittot@linaro.org>
References: <1568878421-12301-1-git-send-email-vincent.guittot@linaro.org>
         <1568878421-12301-10-git-send-email-vincent.guittot@linaro.org>
Content-Type: multipart/signed; micalg="pgp-sha256";
        protocol="application/pgp-signature"; boundary="=-WuD0OLaHXmYk47Pie627"
User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) 
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--=-WuD0OLaHXmYk47Pie627
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 2019-09-19 at 09:33 +0200, Vincent Guittot wrote:
> runnable load has been introduced to take into account the case where
> blocked load biases the wake up path which may end to select an
> overloaded
> CPU with a large number of runnable tasks instead of an underutilized
> CPU with a huge blocked load.
>=20
> Tha wake up path now starts to looks for idle CPUs before comparing
> runnable load and it's worth aligning the wake up path with the
> load_balance.
>=20
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>

On a single socket system, patches 9 & 10 have the
result of driving a woken up task (when wake_wide is
true) to the CPU core with the lowest blocked load,
even when there is an idle core the task could run on
right now.

With the whole series applied, I see a 1-2% regression
in CPU use due to that issue.

With only patches 1-8 applied, I see a 1% improvement in
CPU use for that same workload.

Given that it looks like select_idle_sibling and
find_idlest_group_cpu do roughly the same thing, I
wonder if it is enough to simply add an additional
test to find_idlest_group to have it return the
LLC sg, if it is called on the LLC sd on a single
socket system.

That way find_idlest_group_cpu can still find an
idle core like it does today.

Does that seem like a reasonable thing?

I can run tests with that :)

--=20
All Rights Reversed.

--=-WuD0OLaHXmYk47Pie627
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAl2bVj0ACgkQznnekoTE
3oNkvAf9EIx4XCf3dXuBIbnv/VDATAw7RpjAhjca32QZlF2v2HCNkxQsuEWAaPBr
t7grHeoD5jQIvyMulh2+uUJMZylURuPNdDs6+OyF3pHRSGNTMKhPkNGQVlwTmuvf
GHayc0dHmYN/LjzcIGGdKYUnte7laSweKFGckYwSBnCLGwZyNNsIFJVIoohiqrRJ
zf3LlBGrx0HisQdrywzdSJmXQVhCknycNU9N4zhUQkOBShY2r+a/2Q6xXFiw8Nuk
oK0WKqbk09Erqy3sazKJpYy/Lgnf8ji/wT32OO+rwbf/i4RJYcLakSccooyNxdVm
Gb24a8dg/MIyUfUn/vetydJrMNjtwQ==
=rSUF
-----END PGP SIGNATURE-----

--=-WuD0OLaHXmYk47Pie627--