lkml.org 
[lkml]   [2023]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] x86/cpu: Add support for modern x86-64-v* march
On Fri, 7 Jul 2023 at 12:28, Borislav Petkov <bp@alien8.de> wrote:
>
> On Fri, Jul 07, 2023 at 11:56:00AM +0100, Dimitri John Ledkov wrote:
> > Add support for setting march to x86-64-v2, x86-64-v3, x86-64-v4 with
> > tuning set to an early family of CPUs that support such instruction
> > levels. By default gcc sets generic tuning for x86-64-v*, which is
> > suboptimal for all brands of CPUs with such instruction set support.
>
> Prove that it is suboptimal for the kernel. Numbers please.

It's not suboptimal for the kernel as is, it is suboptimal for
march=x86-64-v* as documented in gcc - probably gcc should actually
prohibit mtune=generic with march=x86-64-v* settings.

> And even if it shows on *some* uarch:
>
> * we need a *single* setting for distro kernels - i.e.,
> CONFIG_GENERIC_CPU and compilers do make sure that -mtune=generic does
> the most optimal code generation for all uarches
>
> * our Kconfig option set is abysmal so don't need any more if useless.
>
> Yeah, a patch like that keeps popping up on a regular basis but no,
> thanks.

The biggest issue is that march & mtune is always set, and there is no
option to use the compiler configured builtin default, or pass in an
arbitrary string.

Would it be acceptable to change GENERIC_CPU to not set neither march
nor mtune and thus use the compiler configured default? If not, would
it be acceptable to have a new option GENERIC_NONE which does not set
any march/mtune and thus uses a compiler configured default? Or for
example, allow a new freeform string for march and mtune?

--
okurrr,

Dimitri

\
 
 \ /
  Last update: 2023-07-07 13:47    [W:0.038 / U:1.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site