Re: [PATCH] printf: mark errptr() noinline

[Tamir Duberstein]

On Wed, Apr 8, 2026 at 3:16 AM Petr Mladek <pmladek@xxxxxxxx> wrote:
>
> On Tue 2026-04-07 09:34:57, Tamir Duberstein wrote:
> > On Tue, Apr 7, 2026 at 7:27 AM Petr Mladek <pmladek@xxxxxxxx> wrote:
> > >
> > > On Mon 2026-04-06 12:32:32, Steven Rostedt wrote:
> > > > On Mon, 6 Apr 2026 11:21:39 -0400
> > > > Tamir Duberstein <tamird@xxxxxxxxxx> wrote:
> > > >
> > > > > Thanks Steve. IMO that is a very big hammer and not warranted in this
> > > > > case. There's been talk of encouraging distros to enable CONFIG_KUNIT
> > > > > by default [0], which would probably interact poorly with the change
> > > > > you propose.
> > > > >
> > > >
> > > > Branch profiling is really just a niche that is enabled specifically for
> > > > seeing all branches taken in the kernel. It hooks to all "if" statements!
> > > > As you can imagine, it causes a rather large overhead in performance.
> > > >
> > > > This option is only used by developers doing special analysis of their code
> > > > (namely me ;-).
> > > >
> > > > The only real concern I would have is if the kunit test developers would
> > > > want to use the branch profiling on their code, in which case my suggestion
> > > > would prevent that.
> > >
> > > I wonder if it might be possible to disable the branch profiling just
> > > for the printf_kunit.c as a compromise.
> > >
> > > Would "#undef if" in printf_kunit.c help?
> > >
> > > Or I see that DISABLE_BRANCH_PROFILING is an official
> > > way to disable the feature.
> > >
> > > I wonder if the following change would solve the problem.
> > > I am sorry, I could not test it easily.
> >
> > Yes, we can disable it for the whole file. I decided against that
> > because narrow workarounds are better than broad ones IMO, but it is
> > ultimately up to your preference.
>
> I might be wrong but I think that nobody would want to
> profile/optimize this kunit test. So, this looks like the best
> solution because it is straightforward. The variant adding
> "noinline" looks too hacky to me.
>
> > FWIW I did test that this patch fixes the problem in GCC 8.5.0.
>
> Thanks for testing.
>
> Would you like to prepare a proper patch or should I do so?

Please go ahead with your preferred approach.