Received-SPF: pass (google.com: domain of linux-kernel+bounces-168524-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <267391c1-948c-9f75-69e6-b5b49d34a7fe@quicinc.com>
References: <20240502233017.419365-1-swboyd@chromium.org> <267391c1-948c-9f75-69e6-b5b49d34a7fe@quicinc.com>
From: Stephen Boyd <swboyd@chromium.org>
User-Agent: alot/0.10
Date: Fri, 3 May 2024 22:59:57 -0700
Message-ID: <CAE-0n50Wy0ZEmPfxyacBnwUMNvFgiZ5RXdR-fy+JEjFkNg8=Rg@mail.gmail.com>
Subject: Re: [PATCH] clocksource/drivers/arm_arch_timer: Mark
 validate_timer_rate() init
To: Daniel Lezcano <daniel.lezcano@linaro.org>, Mukesh Ojha <quic_mojha@quicinc.com>, 
	Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, patches@lists.linux.dev, 
	linux-arm-kernel@lists.infradead.org, Jisheng Zhang <jszhang@kernel.org>, 
	Ionela Voinescu <ionela.voinescu@arm.com>, Marc Zyngier <maz@kernel.org>, 
	Mark Rutland <mark.rutland@arm.com>
Content-Type: text/plain; charset="UTF-8"

Quoting Mukesh Ojha (2024-05-03 04:27:52)
>
>
> On 5/3/2024 5:00 AM, Stephen Boyd wrote:
> > Add the __init marking to validate_timer_rate() so that it gets
> > discarded after init.
> >
> >    $ ./scripts/bloat-o-meter vmlinux.before vmlinux.after
> >    add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-8 (-8)
> >    Function                                     old     new   delta
> >    arch_timer_register                         1724    1716      -8
>
> Have not used this tool bloat-o-meter
> Just a question, why is it showing arch_timer_register is shrunk ?

Hmm good question. There shouldn't be any difference if it gets inlined.

It's an allmodconfig build. It looks like that causes noise in the build so it
isn't stable. :( I diffed the objdump and the function is missing this ror and
nop instruction. But then I built it again, and it became more different. If I
build an allnoconfig it has zero difference.

Before:

  ffff800083021ed4:       974ba12d        bl      ffff80008030a388
<free_percpu_irq>
  ffff800083021ed8:       93d3f273        ror     x19, x19, #60
  ffff800083021edc:       d503201f        nop
  ffff800083021ee0:       d29858e0        mov     x0, #0xc2c7
           // #49863
  ffff800083021ee4:       910102b6        add     x22, x21, #0x40
  ffff800083021ee8:       f2aeea20        movk    x0, #0x7751, lsl #16
  ffff800083021eec:       f2ce7680        movk    x0, #0x73b4, lsl #32
  ffff800083021ef0:       f2f09e20        movk    x0, #0x84f1, lsl #48
  ffff800083021ef4:       ca000273        eor     x19, x19, x0
  ffff800083021ef8:       97527f02        bl      ffff8000804c1b00
<__sanitizer_cov_trace_pc>

After:

  ffff800083021ed4:       974ba12d        bl      ffff80008030a388
<free_percpu_irq>
  ffff800083021ed8:       d29f9f00        mov     x0, #0xfcf8
           // #64760
  ffff800083021edc:       910102b6        add     x22, x21, #0x40
  ffff800083021ee0:       f2b03940        movk    x0, #0x81ca, lsl #16
  ffff800083021ee4:       f2d5e700        movk    x0, #0xaf38, lsl #32
  ffff800083021ee8:       f2ee1340        movk    x0, #0x709a, lsl #48
  ffff800083021eec:       ca000273        eor     x19, x19, x0
  ffff800083021ef0:       97527f04        bl      ffff8000804c1b00
<__sanitizer_cov_trace_pc>

Maybe kcov is making things different?