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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 7BA73C43215 for ; Fri, 15 Nov 2019 10:18:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 540AB20748 for ; Fri, 15 Nov 2019 10:18:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="rcgSsPfU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727632AbfKOKSP (ORCPT ); Fri, 15 Nov 2019 05:18:15 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:36822 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727134AbfKOKSO (ORCPT ); Fri, 15 Nov 2019 05:18:14 -0500 Received: by mail-lj1-f195.google.com with SMTP id k15so10108468lja.3 for ; Fri, 15 Nov 2019 02:18:12 -0800 (PST) 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=pCyqOdp+ZndERcZb5iv1sm6YH8+z1aM4ycI4+c8RSn4=; b=rcgSsPfU+Q97tOFNKOrVXTIZo5atGipqubSqP/Zb1Qy3QZH31sW7nEYJ/3pb294IST tDNnwxKaF24pgsnVbJi7SCE/y42+d+VvKJdJbiuGRQciM7uSi/mtLQlkhqy8exd9vIhx a56YtyxTQQn3tHCwIK5QMEa44XQ8nV5ZW3WYlEWLd4jMtaalMOF+NVU8VSU/oE+XQ/d3 nw1ySTNoE585b+1VAaDyZsbOkao9SFZIgIbYbS2gERD/c3P1Z8CiVdAZGuA3NRCSZ/6k mCavaQR2o0D0s1ZJKWQN9pP6WcaK/fCllOY4pg4O/jiCvfBhgoNGlZ4JYUtefzD9zSYp 60eg== 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=pCyqOdp+ZndERcZb5iv1sm6YH8+z1aM4ycI4+c8RSn4=; b=CdFOiLSdTEVfF2g/7Uu78KtT5wohW9RQ0r0uT6YDKPYNycbrQsVuat55YZZWrsz8Yj smVWEObe05LSXs733ut0SOZ1eaZhAimxUR8Sdet006XDo/UalkQkJTdvocW+YdAIo142 y8a/3E7Skeu80QNYFbSdcftlJrs2PyeeWxynSOLnJQjvtlmpoPQWy/arFNXlTR/GdO3F VF7muEYe0r4+R9lAOfltqHfN9+NaACg1wEoxAWooBh9439aiWHOtIw2dj2vswYlsYPle tjj7+bE7bNYDBD9vZMvhvTunLBVkSfUo2dBiKMLjKSq/Fj9N4h3C5+ZWN7Bkbk+YKitO B/XQ== X-Gm-Message-State: APjAAAXKkyyR8kvTToyLtuKXA6k5v4fNBeQ8XkH39ybndAYT7etjhlJ2 yvojHHSp9m3QSp3DVfnuDavkCDx7kuanR/sg8xLF6g== X-Google-Smtp-Source: APXvYqw4nG6xeDVRRT2y9ygXD8V2W7ROQTkc/+zE6SYLloLLqV10hMqTILv/0ihg/0vC+GzCo0u/uuerAQVwKblA97I= X-Received: by 2002:a2e:b0e3:: with SMTP id h3mr10133730ljl.193.1573813091777; Fri, 15 Nov 2019 02:18:11 -0800 (PST) MIME-Version: 1.0 References: <1573751251-3505-1-git-send-email-vincent.guittot@linaro.org> <20191115095447.GU4114@hirez.programming.kicks-ass.net> In-Reply-To: <20191115095447.GU4114@hirez.programming.kicks-ass.net> From: Vincent Guittot Date: Fri, 15 Nov 2019 11:18:00 +0100 Message-ID: Subject: Re: [PATCH v4] sched/freq: move call to cpufreq_update_util To: Peter Zijlstra Cc: linux-kernel , Ingo Molnar , Dietmar Eggemann , Juri Lelli , Steven Rostedt , Mel Gorman , Doug Smythies , "open list:THERMAL" , Linus Torvalds , Thomas Gleixner , Sargun Dhillon , Tejun Heo , Xie XiuQi , xiezhipeng1@huawei.com, Srinivas Pandruvada Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Nov 2019 at 10:55, Peter Zijlstra wrote: > > On Thu, Nov 14, 2019 at 06:07:31PM +0100, Vincent Guittot wrote: > > update_cfs_rq_load_avg() calls cfs_rq_util_change() everytime pelt decays, > > which might be inefficient when cpufreq driver has rate limitation. > > > > When a task is attached on a CPU, we have call path: > > > > update_load_avg() > > update_cfs_rq_load_avg() > > cfs_rq_util_change -- > trig frequency update > > attach_entity_load_avg() > > cfs_rq_util_change -- > trig frequency update > > > > The 1st frequency update will not take into account the utilization of the > > newly attached task and the 2nd one might be discard because of rate > > limitation of the cpufreq driver. > > Doesn't this just show that a dumb rate limit in the driver is broken? But the rate limit may come from HW constraints that forces to wait let say 4ms or even 10ms between each frequency update. > > > update_cfs_rq_load_avg() is only called by update_blocked_averages() > > and update_load_avg() so we can move the call to > > cfs_rq_util_change/cpufreq_update_util() into these 2 functions. It's also > > interesting to notice that update_load_avg() already calls directly > > cfs_rq_util_change() for !SMP case. > > > > This changes will also ensure that cpufreq_update_util() is called even > > when there is no more CFS rq in the leaf_cfs_rq_list to update but only > > irq, rt or dl pelt signals. > > I don't think it does that; that is, iirc the return value of > ___update_load_sum() is 1 every time a period lapses. So even if the avg > is 0 and doesn't change, it'll still return 1 on every period. > > Which is what that dumb rate-limit thing wants of course. But I'm still > thinking that it's stupid to do. If nothing changes, don't generate > events. When everything (irq, dl, rt, cfs) is 0, we don't generate events because update_blocked_averages is no more called because rq->has_blocked_load is clear With current implementation, if cfs is 0 but not irq, dl or rt, we don't call cpufreq_update_util because it is only called through cfs > > If anything, update_blocked_avgerages() should look at > @done/others_have_blocked() to emit events for rt,dl,irq. other_have_blocked can be set but no decay happened during the update and we don't need to call cpufreq_update_util > > So why are we making the scheduler code more ugly instead of fixing that > driver?