Re: [RFC PATCH 25/28] x86: Use PIE codegen for the core kernel

[Andi Kleen <ak@linux.intel.com>]

On Wed, Sep 25, 2024 at 11:23:39PM +0200, Ard Biesheuvel wrote:
> > What matters is what it does to general performance.
> >
> > Traditionally even on x86-64 PIC/E has a cost and the kernel model
> > was intended to avoid that.
> >
> 
> Is the x86_64 kernel C model specified anywhere, to your knowledge?

The basics are in the ABI. Maybe some of the details of TLS / stack
protector are missing (I guess that could be fixed, adding HJ)

Some of the motivation was also in early papers like
https://www.ucw.cz/~hubicka/papers/amd64/amd64.html

I'm copying Honza Hubicka who did the original work.

> 
> > From my perspective this patch kit doesn't fix a real problem,
> > it's all risk of performance regression with no gain.
> >
> 
> It's all in the cover letter and the commit logs so I won't rehash it
> here, but I understand that your priorities may be different from
> mine.

It sounded fairly nebulous to me. If Linux wanted to support a third tool chain
and it didn't support the kernel model yet it would be somehow easier.
Apart from the kernel model likely being one of the minor issues
in such a endeavour, I don't see a third tool chain othan than gcc and llvm
anywhere on the horizon?

> 
> I'll provide some numbers about the impact on code size. Are there any
> other performance related aspects that you think might be impacted by
> the use of position independent code generation?

Code size isn't a sufficient metric either.

Linux sometimes goes to great length for small gains, for example
there was a huge effort to avoid frame pointers, even though it's a
small percentage delta. PIC could well be larger than frame pointers.

You need to run it with some real workloads, e.g. some of the kernel
oriented workloads in 0day or phoronix, and see if there are
performance regressions.

Unfortunately for an intrusive change like this this might also vary for
different CPUs, so may need some more coverage.

-Andi