Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1626514imm; Wed, 16 May 2018 00:14:22 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqjKnyKUtCIC8DER2wjv1xIVf6+QFLi9Ekgf6pEXmmAB6x/3Dsz1pNv8iz7WYcj39HTtKMO X-Received: by 2002:a62:845:: with SMTP id c66-v6mr18658059pfd.189.1526454862458; Wed, 16 May 2018 00:14:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526454862; cv=none; d=google.com; s=arc-20160816; b=Nosqs/zoYIcKHsVQKRZ2PDqybrUX8TIVw7ABWv/MMk2nx+IkDDcFLbwkKD2/ZopHLn IlQXAMQe4mTddXItRhC9QO2S0YaLDLoQP0De8j1LDuZYm5heLpdDyZZKPEJG9NDkkyOa 6BjxWSwfXLqeSz8jR9DE2njndcgKkzZ71GD8gczDxIIPeAZcfv/0lY6pvU5BJa2rTMiV GvVCnaOyjexx6FtcY/dvp+Zla9RHnwOf1tMIlFt4KsZ9da7awgPW1iny4bJQCUnO7+mI /Slo9EKVIzXPuHFDJnP4RX/HXileswA8QdNI/t2H4vAKJVTeHwWU0m4E8T8N+E7ph5Pb cglg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=zVQEnz3rFmVIErEha5YRir99a6ESnMQdWUwG9YVVvcE=; b=b8dbqhLa59X86ZeKux4dI2R4jdu3Qq/Jvc5ymRy3smipizQtw4p35gHcgZMrpBZM3W TqngD24L6k1MGHRqkSH9nHxU2fm2WcrMgvbR/vxG/4dzluTBkku9xDe5KBOP14eu5Y9j bUjVRAd3IErq1QR4K6XGJJNjz9boQTOYayD2hKv7A7fVYLgeZrLy7QVH5KO1hc7uRim6 2c9lIEHAr8iAL0zARZra7FGglcocYMJI/tsXmlbeH54Dsho6c8NS0rxghkv9KSgmD3FQ LUdU5kBEt02pCHYaDHP5ItnJPlLUSMrslXTf3BA6KlLOaMzyQvJroX5cs4EwDhJd9fnU iBqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jkG24gtG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 132-v6si1578263pgb.674.2018.05.16.00.14.08; Wed, 16 May 2018 00:14:22 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jkG24gtG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1752500AbeEPHNn (ORCPT + 99 others); Wed, 16 May 2018 03:13:43 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:38008 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751151AbeEPHNm (ORCPT ); Wed, 16 May 2018 03:13:42 -0400 Received: by mail-it0-f67.google.com with SMTP id q4-v6so8589682ite.3 for ; Wed, 16 May 2018 00:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zVQEnz3rFmVIErEha5YRir99a6ESnMQdWUwG9YVVvcE=; b=jkG24gtGI09uWiecSCB3cC5BrmpbnOblV3bi1dSs/zEsdX9tsfpN3yIVXN1vv9lQdA qUrlTglbRvpMKOulTBDUyAATh1WH0D7qaqz6LveoMqNIcr0zk+7ueTLIIc/1044FVnoV KOu0ByBEmlfUMZUyr7ZSS0JhcZNLFzzaENfZY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zVQEnz3rFmVIErEha5YRir99a6ESnMQdWUwG9YVVvcE=; b=E/nNlgIbTAQz+LW+mPSc8eRjPWH947nw6aTk3kM/p/hTGXuASo4iuJmE1u6gsfRAMw YnvamhpZFerQHZBrcxO8/qgHtPd5+gKJfCpa7qRn379nuTjToxG445td+bKVQu3+qGI1 Ncn2FKOhSpEfmrp6znM+YHsenbcfuR4oqd4szmpBbmubHek8/aZXFFT7MHjbUfS/gkUk m9+CRvJn5JmA/0wZDk3K0znwALkwP1ThPrU89wf6yC7pGJwWkyalI/JndUbsvjIRJ3gA 0iFVVN3zv/NGRcBfcBYoMsv8bnfoRCu+cWQ5lSHVpn9QoUi4LodyRyt1ClT8AVh+TmOM IXmA== X-Gm-Message-State: ALKqPwe7ZuGQOzenVbwFKG5iYjFYzlucOARYO+7RZcMZ/ZMtMSfIbAMb d1O/Z2G8OXjvVA5mHASOI6cfjmJ7EyHT3nUPv81irA== X-Received: by 2002:a6b:c8c8:: with SMTP id y191-v6mr19300275iof.295.1526454821374; Wed, 16 May 2018 00:13:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.4.204 with HTTP; Wed, 16 May 2018 00:13:20 -0700 (PDT) In-Reply-To: <20180515165304.GH12217@hirez.programming.kicks-ass.net> References: <20180510150553.28122-1-patrick.bellasi@arm.com> <20180510150553.28122-4-patrick.bellasi@arm.com> <20180513060443.GB64158@joelaf.mtv.corp.google.com> <20180513062538.GA116730@joelaf.mtv.corp.google.com> <20180514163206.GF30654@e110439-lin> <20180515145343.GJ30654@e110439-lin> <20180515165304.GH12217@hirez.programming.kicks-ass.net> From: Vincent Guittot Date: Wed, 16 May 2018 09:13:20 +0200 Message-ID: Subject: Re: [PATCH 3/3] sched/fair: schedutil: explicit update only when required To: Peter Zijlstra Cc: Patrick Bellasi , Joel Fernandes , linux-kernel , "open list:THERMAL" , Ingo Molnar , "Rafael J . Wysocki" , Viresh Kumar , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Joel Fernandes , Steve Muckle 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 15 May 2018 at 18:53, Peter Zijlstra wrote: > On Tue, May 15, 2018 at 03:53:43PM +0100, Patrick Bellasi wrote: >> On 15-May 12:19, Vincent Guittot wrote: >> > On 14 May 2018 at 18:32, Patrick Bellasi wrote: > >> > Yes se becomes NULL only when you reach root domain > > root group; domains are something else again ;-) yes good point :-) > >> Thus, the scheduler knows that we are going to sleep: does is really >> makes sense to send a notification in this case? > > It might; esp. on these very slow changing machines. > >> What about adding a new explicit callback at the end of: >> update_blocked_averages() ? >> >> Something like: >> >> ---8<--- >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index cb77407ba485..6eb0f31c656d 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -7740,6 +7740,9 @@ static void update_blocked_averages(int cpu) >> if (done) >> rq->has_blocked_load = 0; >> #endif >> + >> + cpufreq_update_util(rq, SCHED_CPUFREQ_IDLE); >> + >> rq_unlock_irqrestore(rq, &rf); >> } >> ---8<--- >> >> Where we can also pass in a new SCHED_CPUFREQ_IDLE flag just to notify >> schedutil that the CPU is currently IDLE? >> >> Could that work? > > Simlarly you could add ENQUEUE/DEQUEUE flags I suppose. But let's do all > that later in separate patches and evaluate the impact separately, OK?