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"
Date: Tue, 29 Oct 2019 17:49:55 +0100 [thread overview]
Message-ID: <20191029164955.GO4131@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAKfTPtD79VE+gqffpBAGd39bJKe7ao+jbmVSQ7PtS=dky0Wx6g@mail.gmail.com>
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?
next prev parent reply other threads:[~2019-10-29 16:50 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 15:55 [PATCH] Revert "sched/fair: Fix O(nr_cgroups) in the load balancing path" Doug Smythies
2019-10-25 16:51 ` Vincent Guittot
2019-10-26 6:59 ` Doug Smythies
2019-10-28 8:21 ` Vincent Guittot
2019-10-29 14:55 ` Doug Smythies
2019-10-29 15:36 ` Peter Zijlstra
2019-10-29 16:20 ` Vincent Guittot
2019-10-29 16:49 ` Peter Zijlstra [this message]
2019-10-29 17:00 ` Vincent Guittot
2019-10-29 17:09 ` Vincent Guittot
2019-10-29 16:02 ` Vincent Guittot
2019-10-30 14:04 ` Doug Smythies
2019-10-30 15:27 ` Vincent Guittot
2019-11-08 9:18 ` Vincent Guittot
2019-11-09 16:47 ` Doug Smythies
2019-11-10 15:13 ` Vincent Guittot
2019-10-29 19:34 ` Srinivas Pandruvada
2019-10-29 19:59 ` Srinivas Pandruvada
2019-10-30 15:54 ` Doug Smythies
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191029164955.GO4131@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dsmythies@telus.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=riel@surriel.com \
--cc=sargun@sargun.me \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vincent.guittot@linaro.org \
--cc=xiexiuqi@huawei.com \
--cc=xiezhipeng1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).