public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Valentin Schneider <valentin.schneider@arm.com>
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 12:57:23 +0100	[thread overview]
Message-ID: <20200619115723.GF3129@suse.de> (raw)
In-Reply-To: <jhjwo43cpfl.mognet@arm.com>

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. 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.

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2020-06-19 11:57 UTC|newest]

Thread overview: 26+ 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 10:36   ` Valentin Schneider
2020-06-19 11:57     ` Mel Gorman [this message]
2020-06-19 12:17       ` Valentin Schneider
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=20200619115723.GF3129@suse.de \
    --to=mgorman@suse.de \
    --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=mingo@redhat.com \
    --cc=patrick.bellasi@matbug.net \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=valentin.schneider@arm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox