Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4517968imw; Tue, 19 Jul 2022 08:05:55 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sF0750qaNW3HHrmso+qapHCBynNsKKG83LNOzv8affAxqUoyuaHSX+6aUHMSXADxc77v0y X-Received: by 2002:a05:6808:238d:b0:33a:7c9b:a1c7 with SMTP id bp13-20020a056808238d00b0033a7c9ba1c7mr4290333oib.7.1658243155133; Tue, 19 Jul 2022 08:05:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658243155; cv=none; d=google.com; s=arc-20160816; b=ZeUEeM2s+WEQ0PvG8PgtShXiFarMlf6nPvKk1kk9eriY8kAHeAuG7ezS1iCfBpKWWD +MSXnwVhbB6lM6bK+ZOt05iU0T9ypBYyFAMF2wuBLQoEb/q20KlRvn56oK73oR/uqe5u VWrdq91unoUEzmrMWYrSbZs3L7D8nc9WN0GbsDOnEsgkCYZl3hpVRKAqkwJ4WyDEHjgj HqcTg7tTqAOXhudH7Qb5oyISzXg1wDkn7ipKJcK4uQBBksvoDLessNJypzq3CSAoMNsv Kufpa+DQ0ivL9gIe206aFjvAtPLYcpzSIJ2KbekiSL7jLbbkqncKcKYtgtY55+R9mOCC MjnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=RCaDJzWeU7u8SxY7kO+KY73YKoXoX8uh6F8cVhpLoJ4=; b=pefqmX8NK9qINL71EKNdkUpbeFICtwp5Su1doFKrpfuIqVw2ha5/QcOf1Pl5plrspm kCb0ymLn3VvTfSUb1c8+4IO4RpOq4rMggTXBUqxw13Etfrp36i8rz2UO8NDwcYvcb14+ 8vJ6CZr7Rx2clyMe2ddAmUAuKIAS3kZYQVoCbZ6PMKW5Zf+/WpT+OTx2Nhklfp8cVO9a 86ySWFwjG3Kt8c95dt1FTnH6zgW4m3J5O3NXg+XzWCxvzEn9EgsXC79T3U/pbMGHeinW qNkmFnc7xlZ3UV4ghoxT1OTyxSR/OC7mBshMnNAYnVTXpjMNz027N1fWk803gdy6I4ds 3YYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=JyTkRXsW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 12-20020aca120c000000b0033a8bc8f815si2544568ois.170.2022.07.19.08.05.41; Tue, 19 Jul 2022 08:05:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=JyTkRXsW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238162AbiGSOGV (ORCPT + 99 others); Tue, 19 Jul 2022 10:06:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37714 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238067AbiGSOF7 (ORCPT ); Tue, 19 Jul 2022 10:05:59 -0400 Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8A1E48C94 for ; Tue, 19 Jul 2022 06:20:27 -0700 (PDT) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-31bf3656517so140111457b3.12 for ; Tue, 19 Jul 2022 06:20:27 -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=RCaDJzWeU7u8SxY7kO+KY73YKoXoX8uh6F8cVhpLoJ4=; b=JyTkRXsWldJMf4Kc2h0+DBT+fb4TjT7xeSUptHrwXQ0PsExdUVAlc+SGa7KmXlF/aq SutXy06HPfDy4RsHcBmPEQOEYhjOjLE+6rvXu4UHyUQpQyAKWj/3UhQWXMjcSLHbAN6r kp87t3bQdqUeTuGub86nQa6lCG0m01RKQ9qJaOCeBgGFYkUuWEChXexT0TmhwSytPO3M RJKOpgbwK+Ct2nyTnwxDjUg0SgzRDyjMXB4us5OSm0TnBQuc3olkuIEBgbKfg1vO9hF7 bWoOpoRf9aQ3CTj4v71lfm5+z97CW3aPbLNyu8C+ajLDVs4BFL+vCUJoAub9lbhg60I2 aR7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RCaDJzWeU7u8SxY7kO+KY73YKoXoX8uh6F8cVhpLoJ4=; b=C96V77DrPYkcvw2g+Rwjc5t/ue7K8EhVS5x6dD/ULlSM/dylqRfGdmlmcyhejRv3mu nOhCDRaNszGkYOZAiz91ojcFqC9bpSWaR8GAcGXfte1bc8H/KXYWK1CXZ2FiI7YsGzgt KS2iYIR5MYnBkrkyTeX7ajiNAkYY88PKQ8fyw/1l4M7QfMwWJP9x3P289T1ST8l6mKXU 5qMP6tNyWBiD26YJ/lVaXBxI6/Hp6d/hZo13Y/sgGTKJFqBBb9I7YY3GpHUZC4O5bYU5 r6Iy39CqvIXLVNB7os3gcECvGDWnK+pIxs98ULpuXjc6PCQLYFEtU/Fh7nznxxaYwpMK dHxg== X-Gm-Message-State: AJIora9e78214RJOKOOkx7RgRoNOq6z9SeJenjIhcuQl6b0xOqgn3rD0 PzdRq5fLLeCGQIhs1zqXO9E3iFsJfMvG3bW1e1HxSg== X-Received: by 2002:a81:4319:0:b0:31d:92c4:9e5f with SMTP id q25-20020a814319000000b0031d92c49e5fmr35705592ywa.359.1658236826480; Tue, 19 Jul 2022 06:20:26 -0700 (PDT) MIME-Version: 1.0 References: <20220713040430.25778-1-zhouchengming@bytedance.com> <20220713040430.25778-10-zhouchengming@bytedance.com> In-Reply-To: <20220713040430.25778-10-zhouchengming@bytedance.com> From: Vincent Guittot Date: Tue, 19 Jul 2022 15:20:15 +0200 Message-ID: Subject: Re: [PATCH v2 09/10] sched/fair: stop load tracking when task switched_from_fair() To: Chengming Zhou Cc: mingo@redhat.com, peterz@infradead.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, vschneid@redhat.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 13 Jul 2022 at 06:05, Chengming Zhou wrote: > > The same reason as the previous commit, if we don't reset the > sched_avg last_update_time to 0, after a while in switched_to_fair(): > > switched_to_fair > attach_task_cfs_rq > attach_entity_cfs_rq > update_load_avg > __update_load_avg_se(now, cfs_rq, se) > > The delta (now - sa->last_update_time) will wrongly contribute/decay > sched_avg depends on the task running/runnable status at that time. I think that we always decay the time spent in !fair class and never contribute This one is a bit more complex than the new task one. Generally speaking, I would say that we should decay the load while running in !fair case because the value becomes less and less relevant over time. What's the meaning of pelt values when the task has run seconds as a fifo ? The only case that would need a particular attention, is the pi boost case but there is no way to now how long is runs and sleep when !fair > > This patch reset it's sched_avg last_update_time to 0, stop load > tracking for !fair task, later in switched_to_fair() -> > update_load_avg(), we can use its saved sched_avg. > > Signed-off-by: Chengming Zhou > --- > kernel/sched/fair.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 50f65a2ede32..576028f5a09e 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -11552,6 +11552,11 @@ static void attach_task_cfs_rq(struct task_struct *p) > static void switched_from_fair(struct rq *rq, struct task_struct *p) > { > detach_task_cfs_rq(p); > + > +#ifdef CONFIG_SMP > + /* Stop load tracking for !fair task */ > + p->se.avg.last_update_time = 0; > +#endif > } > > static void switched_to_fair(struct rq *rq, struct task_struct *p) > -- > 2.36.1 >