All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Mel Gorman <mgorman@suse.de>, Doug Smythies <dsmythies@telus.net>,
	Linux PM <linux-pm@vger.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>
Subject: Re: [PATCH v4] sched/freq: move call to cpufreq_update_util
Date: Fri, 15 Nov 2019 11:03:20 +0100	[thread overview]
Message-ID: <CAJZ5v0hjsWM=bRg4k2qNCfcqjQ08N+6kG=1vCXpjbi5qEx7utw@mail.gmail.com> (raw)
In-Reply-To: <20191115095447.GU4114@hirez.programming.kicks-ass.net>

On Fri, Nov 15, 2019 at 10:55 AM Peter Zijlstra <peterz@infradead.org> 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?
>
> > 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.
>
> If anything, update_blocked_avgerages() should look at
> @done/others_have_blocked() to emit events for rt,dl,irq.
>
> So why are we making the scheduler code more ugly instead of fixing that
> driver?

I guess we could "fix" the driver by making it rate limit MSR writes
only, but I'm not sure if that would help.

  reply	other threads:[~2019-11-15 10:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-14 17:07 [PATCH v4] sched/freq: move call to cpufreq_update_util Vincent Guittot
2019-11-15  9:54 ` Peter Zijlstra
2019-11-15 10:03   ` Rafael J. Wysocki [this message]
2019-11-15 10:40     ` Peter Zijlstra
2019-11-15 11:05       ` Vincent Guittot
2019-11-15 10:18   ` Vincent Guittot
2019-11-15 10:29     ` Vincent Guittot
2019-11-15 11:59       ` Vincent Guittot
2019-11-15 12:25         ` Vincent Guittot
2019-11-15 10:37     ` Peter Zijlstra
2019-11-15 10:46       ` Vincent Guittot
2019-11-15 10:51         ` Peter Zijlstra
2019-11-15 11:03           ` Vincent Guittot
2019-11-15 11:56             ` Peter Zijlstra
2019-11-15 13:01             ` Peter Zijlstra
2019-11-15 13:30               ` Vincent Guittot
2019-11-15 13:46                 ` Peter Zijlstra
2019-11-15 15:30               ` Doug Smythies
2019-11-15 10:51         ` Rafael J. Wysocki
2019-11-15 12:17         ` Peter Zijlstra
2019-11-15 11:46 ` Rafael J. Wysocki
2019-11-15 13:25 ` Peter Zijlstra
2019-11-15 13:37   ` Vincent Guittot
2019-11-15 14:05     ` Peter Zijlstra
2019-11-15 14:12       ` Vincent Guittot
2019-11-15 15:12     ` Peter Zijlstra
2019-11-15 15:31       ` Vincent Guittot
2019-11-15 17:43         ` Peter Zijlstra
2019-11-15 18:00           ` Vincent Guittot
2019-11-15 20:12             ` Peter Zijlstra
2019-11-15 21:52 ` Peter Zijlstra
2019-11-16  8:47   ` Vincent Guittot
2019-11-16 15:07     ` 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='CAJZ5v0hjsWM=bRg4k2qNCfcqjQ08N+6kG=1vCXpjbi5qEx7utw@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=dsmythies@telus.net \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.