[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180628093738.GE2494@hirez.programming.kicks-ass.net>
Date: Thu, 28 Jun 2018 11:37:38 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
the arch/x86 maintainers <x86@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Arnd Bergmann <arnd@...db.de>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 2/5] kernel/jump_label: implement generic support for
relative references
On Thu, Jun 28, 2018 at 11:29:40AM +0200, Ard Biesheuvel wrote:
> On 28 June 2018 at 11:25, Peter Zijlstra <peterz@...radead.org> wrote:
> >> > Meh. I thought IS_ENABLED() was preferred over #ifdef, no?
> >
> > Dunno, I just reacted to the proposed code's uglyness :-)
> >
>
> I will try to come up with something that rhymes, ok? :-)
:-)
> >> ... and it means the sort() routine will unconditionally perform an
> >> indirect function call even if the arch does not require it.
> >
> > Yeah, not sure I care about that here, this is a one time affair, very
> > far away from any fast paths.
> >
>
> Fair enough.
I recently had thoughts about doing the sort at link time, but then I
figured I didn't care enough to go write the tool to do that. The reason
was in that other patch-set that might conflict, that wants to use jump
labels _very_ early (for x86), so we had to lift the ideal nops stuff
and the cpu feature bits it relies upon to early code.
All in all the patch wasn't terrible and that made me completely loose
interest about doing the link-time thing again.
However, if someone is 'concerned' about the boot time performance, and
figures avoiding the sort is somehow worth it, they can look into it.
Powered by blists - more mailing lists