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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 73F3AC2B9F8 for ; Tue, 25 May 2021 09:58:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 447546140E for ; Tue, 25 May 2021 09:58:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232732AbhEYKA0 (ORCPT ); Tue, 25 May 2021 06:00:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232635AbhEYKAZ (ORCPT ); Tue, 25 May 2021 06:00:25 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EFD1C061756 for ; Tue, 25 May 2021 02:58:56 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id r5so45145909lfr.5 for ; Tue, 25 May 2021 02:58:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sjbcK+Lm3wd8drmc6dOvHnavMF6nKfqCuTFG5UI3Qd8=; b=DWqjd2ZKj4VEhFiAqyMPJlky9QQ+735WWEjgMnIsSYMqSpSjQkNUbljyLplf0Od0++ AcFT7Wo+/xrlCoOjIpU4QFDDsG5S1mGxrZDAHommxfpUHh8DJ/TAdiEiOLvXSXHZhq0T 9ebM5TkLnRx5Q8XHH73oSzJD7pANRwp0lRmbAoZkAC8J74Zs+a4SsR0l21gK8XmDyGh3 9aj1WThK7gWR9z7zgseDW46BDdp4/W+CFfeMILarc2aDIwm1U1lN8X0y3gZhuEV4LnwT EXZFzHfumREOHr42Ls1/R0I8LrZTrDvKEiP30kBUCl8UOwxVF2N+dhp1FdPCckhKA5Zx u6Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sjbcK+Lm3wd8drmc6dOvHnavMF6nKfqCuTFG5UI3Qd8=; b=nkebLtW446Fik4gBJOW6dEiORgk1LJaosO3KCC20jN5DjgcdohEeZoTLt1ImQNmu/4 mYKFJaQzdFaTiECphj7PFeTi15UGvrhigna3IKb2IZ+auOl9nowMNALTF28poBdTQ0Ty m/sM8WNmFlASRbQTjLJBLNkMWtE5/fjzvu1e/2AW3Ncnn9wGxb/N7p3ZhZomTaSeJPNC u2vkJSi9bdoJt2mFJ3oSTYX59cSt/QWN3qZtKiCafBTsk20cyXv+NxERyhOWgzq4Coby 3n4I4GxEUGY/edyju/9hXkvjMkBsmDeUneEZlSiPY4fIq+I5KnrJPjw8ANozhhqfZVGm 9RZA== X-Gm-Message-State: AOAM532a/IKgaeodtJ5HF1RorOFJWDhJDgaJvcCw1M5FRbLVfi78rl+N 9MZd7Yhg5XKNY7zzW3Q02pojSgQu82XvuBdKlz07JQ== X-Google-Smtp-Source: ABdhPJymEHH3L6C2Dr9IFjs4dvQW51E+pLbDYgD29AlubRHXAG2hE6qTDbkp8Lkz7Md6B6iTjqHJcKnLiiwsXO3MSnY= X-Received: by 2002:a05:6512:2205:: with SMTP id h5mr13907940lfu.233.1621936734446; Tue, 25 May 2021 02:58:54 -0700 (PDT) MIME-Version: 1.0 References: <20210518125202.78658-1-odin@uged.al> <20210518125202.78658-2-odin@uged.al> In-Reply-To: <20210518125202.78658-2-odin@uged.al> From: Vincent Guittot Date: Tue, 25 May 2021 11:58:43 +0200 Message-ID: Subject: Re: [PATCH 1/3] sched/fair: Add tg_load_contrib cfs_rq decay checking To: Odin Ugedal Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , "open list:CONTROL GROUP (CGROUP)" , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 18 May 2021 at 14:54, Odin Ugedal wrote: > > Make sure cfs_rq does not contribute to task group load avg when > checking if it is decayed. Due to how the pelt tracking works, > the divider can result in a situation where: > > cfs_rq->avg.load_sum = 0 > cfs_rq->avg.load_avg = 4 Could you give more details about how cfs_rq->avg.load_avg = 4 but cfs_rq->avg.load_sum = 0 ? cfs_rq->avg.load_sum is decayed and can become null when crossing period which implies an update of cfs_rq->avg.load_avg. This means that your case is generated by something outside the pelt formula ... like maybe the propagation of load in the tree. If this is the case, we should find the error and fix it > cfs_rq->avg.tg_load_avg_contrib = 4 > > If pelt tracking in this case does not cross a period, there is no > "change" in load_sum, and therefore load_avg is not recalculated, and > keeps its value. > > If this cfs_rq is then removed from the leaf list, it results in a > situation where the load is never removed from the tg. If that happen, > the fiarness is permanently skewed. > > Fixes: 039ae8bcf7a5 ("sched/fair: Fix O(nr_cgroups) in the load balancing path") > Signed-off-by: Odin Ugedal > --- > kernel/sched/fair.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 3248e24a90b0..ceda53c2a87a 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -8004,6 +8004,9 @@ static inline bool cfs_rq_is_decayed(struct cfs_rq *cfs_rq) > if (cfs_rq->avg.runnable_sum) > return false; > > + if (cfs_rq->tg_load_avg_contrib) > + return false; > + > return true; > } > > -- > 2.31.1 >