From: Peter Zijlstra <peterz@infradead.org>
To: Patrick Bellasi <patrick.bellasi@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
Ingo Molnar <mingo@redhat.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Paul Turner <pjt@google.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Morten Rasmussen <morten.rasmussen@arm.com>,
Juri Lelli <juri.lelli@redhat.com>, Todd Kjos <tkjos@android.com>,
Joel Fernandes <joelaf@google.com>,
Steve Muckle <smuckle@google.com>
Subject: Re: [PATCH v3 1/3] sched/fair: add util_est on top of PELT
Date: Tue, 30 Jan 2018 15:01:32 +0100 [thread overview]
Message-ID: <20180130140132.GI2295@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20180130130432.GC2269@hirez.programming.kicks-ass.net>
On Tue, Jan 30, 2018 at 02:04:32PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 30, 2018 at 12:46:33PM +0000, Patrick Bellasi wrote:
> > > Aside from that being whitespace challenged, did you also try:
> > >
> > > if ((unsigned)((util_est - util_last) + LIM - 1) < (2 * LIM - 1))
> >
> > No, since the above code IMO is so much "easy to parse for humans" :)
>
> Heh, true. Although that's fixable by wrapping it in some helper with a
> comment.
>
> > But, mainly because since the cache alignment update, also while testing on a
> > "big" Intel machine I cannot see regressions on hackbench.
> >
> > This is the code I get on my Xeon E5-2690 v2:
> >
> > if (abs(util_est - util_last) <= (SCHED_CAPACITY_SCALE / 100))
> > 6ba0: 8b 86 7c 02 00 00 mov 0x27c(%rsi),%eax
> > 6ba6: 48 29 c8 sub %rcx,%rax
> > 6ba9: 48 99 cqto
> > 6bab: 48 31 d0 xor %rdx,%rax
> > 6bae: 48 29 d0 sub %rdx,%rax
> > 6bb1: 48 83 f8 0a cmp $0xa,%rax
> > 6bb5: 7e 1d jle 6bd4 <dequeue_task_fair+0x7e4>
> >
> > Does it look so bad?
>
> Its not terrible, and I think your GCC is far more clever than the one I
To clarify; my GCC at the time generated conditional branches to compute
the absolute value; and in that case the thing I proposed wins hands
down because its unconditional.
However the above is also unconditional and then the difference is much
less important.
> used at the time. But that's 4 dependent instructions (cqto,xor,sub,cmp)
> whereas the one I proposed uses only 2 (add,cmp).
>
> Now, my proposal is, as you say, somewhat hard to read, and it also
> doesn't work right when our values are 'big' (which they will not be in
> our case, because util has a very definite bound), and I suspect you're
> right that ~2 cycles here will not be measurable.
>
> So yeah.... whatever ;-)
next prev parent reply other threads:[~2018-01-30 14:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 18:08 [PATCH v3 0/3] Utilization estimation (util_est) for FAIR tasks Patrick Bellasi
2018-01-23 18:08 ` [PATCH v3 1/3] sched/fair: add util_est on top of PELT Patrick Bellasi
2018-01-24 16:40 ` Joel Fernandes
2018-01-24 19:16 ` Patrick Bellasi
2018-01-24 22:06 ` Joel Fernandes
2018-01-29 16:36 ` Peter Zijlstra
2018-01-30 12:46 ` Patrick Bellasi
2018-01-30 13:04 ` Peter Zijlstra
2018-01-30 14:01 ` Peter Zijlstra [this message]
2018-02-05 17:49 ` Patrick Bellasi
2018-01-23 18:08 ` [PATCH v3 2/3] sched/fair: use util_est in LB and WU paths Patrick Bellasi
2018-01-24 11:33 ` Pavan Kondeti
2018-01-24 19:31 ` Patrick Bellasi
2018-01-25 14:33 ` Pavan Kondeti
2018-01-31 15:32 ` Patrick Bellasi
2018-01-23 18:08 ` [PATCH v3 3/3] sched/cpufreq_schedutil: use util_est for OPP selection Patrick Bellasi
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=20180130140132.GI2295@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=morten.rasmussen@arm.com \
--cc=patrick.bellasi@arm.com \
--cc=pjt@google.com \
--cc=rafael.j.wysocki@intel.com \
--cc=smuckle@google.com \
--cc=tkjos@android.com \
--cc=vincent.guittot@linaro.org \
--cc=viresh.kumar@linaro.org \
/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.