From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91886C433ED for ; Tue, 20 Apr 2021 15:20:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 51ECE613AB for ; Tue, 20 Apr 2021 15:20:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232853AbhDTPVQ (ORCPT ); Tue, 20 Apr 2021 11:21:16 -0400 Received: from shelob.surriel.com ([96.67.55.147]:54008 "EHLO shelob.surriel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232174AbhDTPVP (ORCPT ); Tue, 20 Apr 2021 11:21:15 -0400 Received: from imladris.surriel.com ([96.67.55.152]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lYsB2-0002O2-MJ; Tue, 20 Apr 2021 11:20:36 -0400 Message-ID: <5e21452a727dcd6d3257496a2c42f49bd16e9cb5.camel@surriel.com> Subject: Re: [PATCH v2] sched,fair: skip newidle_balance if a wakeup is pending From: Rik van Riel To: Vincent Guittot Cc: linux-kernel , Kernel Team , Peter Zijlstra , Ingo Molnar , Dietmar Eggemann , Mel Gorman , Valentin Schneider Date: Tue, 20 Apr 2021 11:20:36 -0400 In-Reply-To: References: <20210419125134.5cab12ea@imladris.surriel.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-EQ+bP/elTcYHGVQ0YZqy" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Sender: riel@shelob.surriel.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-EQ+bP/elTcYHGVQ0YZqy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2021-04-20 at 11:04 +0200, Vincent Guittot wrote: > On Mon, 19 Apr 2021 at 18:51, Rik van Riel wrote: > >=20 > > @@ -10688,7 +10697,7 @@ static int newidle_balance(struct rq > > *this_rq, struct rq_flags *rf) > > if (this_rq->nr_running !=3D this_rq->cfs.h_nr_running) > > pulled_task =3D -1; > >=20 > > - if (pulled_task) > > + if (pulled_task || this_rq->ttwu_pending) >=20 > This needs at least a comment to explain why we must clear > this_rq->idle_stamp when this_rq->ttwu_pending is set whereas it is > also done during sched_ttwu_pending() >=20 > > this_rq->idle_stamp =3D 0; I spent some time staring at sched_ttwu_pending and the functions it calls, but I can't seem to spot where it clears rq->idle_stamp, except inside ttwu_do_wakeup where it will end up adding a non-idle period into the rq->avg_idle, which seems wrong. If we are actually idle, and get woken up with a ttwu_queue task, we do not come through newidle_balance, and we end up counting the idle time into the avg_idle number. However, if a task is woken up while the CPU is in newidle_balance, because prev !=3D idle, we should not count that period towards rq->avg_idle, for the same reason we do so when we pulled a task. I'll add a comment in v3 explaining why idle_stamp needs to be 0. --=20 All Rights Reversed. --=-EQ+bP/elTcYHGVQ0YZqy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEKR73pCCtJ5Xj3yADznnekoTE3oMFAmB+8UQACgkQznnekoTE 3oNf9gf/fqJNMjAsb+l+f0a8DZOeWp0jOFn9CKfgNVt8IIdBSl42GLR8WlUa6YBa DMITTb+oFqIFlg2SNVbP3dZ3BnVY7oscerSqoMijvJesIWW1JqdNyH2LiFIBqSA+ fmXSEhkb16e1OGh7rY0JuO1zISj2HIoMV2nr5TQFdn9t2xK9Rdim8rsYBQ4oT/kT fDwyWbCv+3DBGr/wythDgFrvQfprN/1MLjnRK24Mw0U55gttDObdERKcnY0GKNFb DmHiVdbwg28P5UUhG3+gWYwlKbMR+4nKbg9yGZ+J/PCJP/GFFNN4q6SrzpxaAGQk V/ePa0wO8Va1ApMyJgQq47Qc7xZsMA== =UM3R -----END PGP SIGNATURE----- --=-EQ+bP/elTcYHGVQ0YZqy--