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;
Date:   Tue, 29 Oct 2019 17:49:55 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Vincent Guittot <vincent.guittot@linaro.org>
Cc:     Doug Smythies <dsmythies@telus.net>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        "open list:THERMAL" <linux-pm@vger.kernel.org>,
        Ingo Molnar <mingo@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Sargun Dhillon <sargun@sargun.me>, Tejun Heo <tj@kernel.org>,
        Xie XiuQi <xiexiuqi@huawei.com>, xiezhipeng1@huawei.com,
        Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
        Rik van Riel <riel@surriel.com>
Subject: Re: [PATCH] Revert "sched/fair: Fix O(nr_cgroups) in the load
 balancing path"
Message-ID: <20191029164955.GO4131@hirez.programming.kicks-ass.net>
References: <1572018904-5234-1-git-send-email-dsmythies@telus.net>
 <CAKfTPtDFAS3TiNaaPoEXFZbqdMt_-tfGm9ffVcQAN=Mu_KbRdQ@mail.gmail.com>
 <000c01d58bca$f5709b30$e051d190$@net>
 <CAKfTPtDx6nu7YtYN=JLRAseZS3Q6Nt-QdMQuG_XoUtmtR_101A@mail.gmail.com>
 <001201d58e68$eaa39630$bfeac290$@net>
 <20191029153615.GP4114@hirez.programming.kicks-ass.net>
 <CAKfTPtD79VE+gqffpBAGd39bJKe7ao+jbmVSQ7PtS=dky0Wx6g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAKfTPtD79VE+gqffpBAGd39bJKe7ao+jbmVSQ7PtS=dky0Wx6g@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Oct 29, 2019 at 05:20:56PM +0100, Vincent Guittot wrote:
> On Tue, 29 Oct 2019 at 16:36, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Tue, Oct 29, 2019 at 07:55:26AM -0700, Doug Smythies wrote:
> >
> > > I only know that the call to the intel_pstate driver doesn't
> > > happen, and that it is because cfs_rq_is_decayed returns TRUE.
> > > So, I am asserting that the request is not actually decayed, and
> > > should not have been deleted.
> >
> > So what cfs_rq_is_decayed() does is allow a cgroup's cfs_rq to be
> > removed from the list.
> >
> > Once it is removed, that cfs_rq will no longer be checked in the
> > update_blocked_averages() loop. Which means done has less chance of
> > getting false. Which in turn means that it's more likely
> > rq->has_blocked_load becomes 0.
> >
> > Which all sounds good.
> >
> > Can you please trace what keeps the CPU awake?
> 
> I think that the sequence below is what intel pstate driver was using
> 
> rt/dl task wakes up and run for some times
> rt/dl pelt signal is no more null so periodic decay happens.
> 
> before optimization update_cfs_rq_load_avg() for root cfs_rq was
> called even if pelt was null,
> which calls cfs_rq_util_change,  which calls intel pstate
> 
> after optimization its no more called.

Not calling cfs_rq_util_change() when it doesn't change, seems like the
right thing. Why would intel_pstate want it called when it doesn't
change?