From: Peter Zijlstra <peterz@infradead.org>
To: Yuyang Du <yuyang.du@intel.com>
Cc: bsegall@google.com, mingo@redhat.com,
linux-kernel@vger.kernel.org, rafael.j.wysocki@intel.com,
arjan.van.de.ven@intel.com, len.brown@intel.com,
alan.cox@intel.com, mark.gross@intel.com, pjt@google.com,
fengguang.wu@intel.com
Subject: Re: [PATCH 2/2] sched: Rewrite per entity runnable load average tracking
Date: Fri, 11 Jul 2014 10:47:09 +0200 [thread overview]
Message-ID: <20140711084709.GF20603@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <20140710232207.GC12984@intel.com>
On Fri, Jul 11, 2014 at 07:22:07AM +0800, Yuyang Du wrote:
> On Thu, Jul 10, 2014 at 12:08:59PM +0200, Peter Zijlstra wrote:
> >
> > Since clock_task is the regular clock minus some local amount, the
> > difference between two regular clock reads is always a strict upper
> > bound on clock_task differences.
> >
> This is inspiring. Regarding the clock source in load avg tracking,
> should we simply use rq_clock_task instead of cfs_rq_clock_task.
Oh *groan* I forgot about that thing. But no, it obviously doesn't
matter for running time, because if you're throttled you're nor running
and therefore it all doesn't matter, but it can make a huge difference
for blocked time accounting I suppose.
> For the bandwidth control case, just update/increase the last_update_time when
> unthrottled by this throttled time, so the time would look like freezed. Am I
> understanding right?
Yes, it stops the clock when throttled.
> Not sure how much bandwidth control is used, but even not used, every time
> we read cfs_rq_clock_task, will burn useless cycles here.
Yep, nothing much you can do about that.
In any case, it is still the case that a normal clock difference is an
upper bound.
next prev parent reply other threads:[~2014-07-11 8:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-02 2:30 [PATCH 1/2] sched: Remove update_rq_runnable_avg Yuyang Du
2014-07-02 2:30 ` [PATCH 2/2] sched: Rewrite per entity runnable load average tracking Yuyang Du
2014-07-07 10:07 ` Peter Zijlstra
2014-07-07 10:46 ` Peter Zijlstra
2014-07-07 20:03 ` Yuyang Du
2014-07-07 22:25 ` bsegall
2014-07-08 0:08 ` Yuyang Du
2014-07-08 17:04 ` bsegall
2014-07-09 1:07 ` Yuyang Du
2014-07-09 17:08 ` bsegall
2014-07-09 18:39 ` Yuyang Du
2014-07-09 18:45 ` Peter Zijlstra
2014-07-09 19:07 ` bsegall
2014-07-10 10:08 ` Peter Zijlstra
2014-07-10 17:01 ` bsegall
2014-07-10 19:53 ` Yuyang Du
2014-07-10 23:22 ` Yuyang Du
2014-07-11 8:47 ` Peter Zijlstra [this message]
2014-07-11 0:52 ` Yuyang Du
2014-07-11 2:01 ` Yuyang Du
2014-07-09 23:30 ` Yuyang Du
2014-07-10 17:06 ` bsegall
2014-07-10 20:08 ` Yuyang Du
2014-07-08 12:50 ` Peter Zijlstra
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=20140711084709.GF20603@laptop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alan.cox@intel.com \
--cc=arjan.van.de.ven@intel.com \
--cc=bsegall@google.com \
--cc=fengguang.wu@intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.gross@intel.com \
--cc=mingo@redhat.com \
--cc=pjt@google.com \
--cc=rafael.j.wysocki@intel.com \
--cc=yuyang.du@intel.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.