From: Valentin Schneider <valentin.schneider@arm.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Qais Yousef <qais.yousef@arm.com>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>,
Patrick Bellasi <patrick.bellasi@matbug.net>,
Chris Redpath <chrid.redpath@arm.com>,
Lukasz Luba <lukasz.luba@arm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] sched/uclamp: Protect uclamp fast path code with static key
Date: Fri, 19 Jun 2020 13:17:28 +0100 [thread overview]
Message-ID: <jhjtuz7ckrr.mognet@arm.com> (raw)
In-Reply-To: <20200619115723.GF3129@suse.de>
On 19/06/20 12:57, Mel Gorman wrote:
> On Fri, Jun 19, 2020 at 11:36:46AM +0100, Valentin Schneider wrote:
>> > nouclamp uclamp uclamp-static-key
>> > Hmean send-64 162.43 ( 0.00%) 157.84 * -2.82%* 163.39 * 0.59%*
>> > Hmean send-128 324.71 ( 0.00%) 314.78 * -3.06%* 326.18 * 0.45%*
>> > Hmean send-256 641.55 ( 0.00%) 628.67 * -2.01%* 648.12 * 1.02%*
>> > Hmean send-1024 2525.28 ( 0.00%) 2448.26 * -3.05%* 2543.73 * 0.73%*
>> > Hmean send-2048 4836.14 ( 0.00%) 4712.08 * -2.57%* 4867.69 * 0.65%*
>> > Hmean send-3312 7540.83 ( 0.00%) 7425.45 * -1.53%* 7621.06 * 1.06%*
>> > Hmean send-4096 9124.53 ( 0.00%) 8948.82 * -1.93%* 9276.25 * 1.66%*
>> > Hmean send-8192 15589.67 ( 0.00%) 15486.35 * -0.66%* 15819.98 * 1.48%*
>> > Hmean send-16384 26386.47 ( 0.00%) 25752.25 * -2.40%* 26773.74 * 1.47%*
>> >
>>
>> Am I reading this correctly in that compiling in uclamp but having the
>> static key enabled gives a slight improvement compared to not compiling in
>> uclamp? I suppose the important bit is that we're not seeing regressions
>> anymore, but still.
>>
>
> I haven't reviewed the series in depth because from your review, another
> version is likely in the works.
I don't wait Qais to hate me here - I think you could start the performance
testing on this version if you feel like it, given my comments were mostly
on changelog / debug options - the core of that patch shouldn't change
much.
> However, it is not that unusual to
> see small fluctuations like this that are counter-intuitive. The report
> indicates the difference is likely outside of the noise with * around the
> percentage difference instead of () but it could be small boot-to-boot
> variance, differences in code layout, slight differences in slab usage
> patterns etc. The definitive evidence that uclamp overhead is no there
> is whether the uclamp functions show up in annotated profiles or not.
I see, thanks! I suppose if we have access to individual samples we can
also run some statistical tests / stare at some boxplots to see how it
compares.
next prev parent reply other threads:[~2020-06-19 12:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-18 19:55 [PATCH 0/2] sched: Optionally skip uclamp logic in fast path Qais Yousef
2020-06-18 19:55 ` [PATCH 1/2] sched/uclamp: Fix initialization of strut uclamp_rq Qais Yousef
2020-06-19 10:36 ` Valentin Schneider
2020-06-19 17:30 ` Peter Zijlstra
2020-06-19 17:39 ` Qais Yousef
2020-06-19 18:13 ` Peter Zijlstra
2020-06-19 18:42 ` Qais Yousef
2020-06-22 10:30 ` Qais Yousef
2020-06-18 19:55 ` [PATCH 2/2] sched/uclamp: Protect uclamp fast path code with static key Qais Yousef
2020-06-19 0:09 ` kernel test robot
2020-06-19 0:09 ` [RFC PATCH] sched/uclamp: sched_uclamp_unused can be static kernel test robot
2020-06-19 10:36 ` [PATCH 2/2] sched/uclamp: Protect uclamp fast path code with static key Valentin Schneider
2020-06-19 11:57 ` Mel Gorman
2020-06-19 12:17 ` Valentin Schneider [this message]
2020-06-19 12:55 ` Qais Yousef
2020-06-19 14:51 ` Qais Yousef
2020-06-19 12:51 ` Qais Yousef
2020-06-19 13:23 ` Steven Rostedt
2020-06-19 13:25 ` Valentin Schneider
2020-06-19 14:13 ` Qais Yousef
2020-06-19 15:17 ` Valentin Schneider
2020-06-19 17:25 ` Qais Yousef
2020-06-19 18:52 ` Valentin Schneider
2020-06-19 19:47 ` Peter Zijlstra
2020-06-19 10:39 ` Valentin Schneider
2020-06-19 17:45 ` Peter Zijlstra
2020-06-19 17:53 ` Qais Yousef
2020-06-22 9:06 ` [PATCH 0/2] sched: Optionally skip uclamp logic in fast path Lukasz Luba
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=jhjtuz7ckrr.mognet@arm.com \
--to=valentin.schneider@arm.com \
--cc=bsegall@google.com \
--cc=chrid.redpath@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.luba@arm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@matbug.net \
--cc=peterz@infradead.org \
--cc=qais.yousef@arm.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@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.