Re: [PATCH] locking/local_lock: Reduce local_[un]lock_nested_bh() overhead

[Uros Bizjak]

On Wed, Mar 11, 2026 at 4:55 PM Sebastian Andrzej Siewior
<bigeasy@xxxxxxxxxxxxx> wrote:
>
> On 2026-03-09 15:52:34 [+0100], Eric Dumazet wrote:
> > > +void ericeric(void);
> > > +void ericeric(void)
> > > +{
> > > +       raw_cpu_read_long(this_cpu_off);
> > > +       raw_cpu_read_long(this_cpu_off);
> > > +}
> > >
> > > I am guessing __raw_cpu_read() is forcing the asm ?
> >
> > Might be a clang issue. Oh well.
>
> So the difference is that with gcc we have USE_X86_SEG_SUPPORT and with
> llvm we don't. This leads to two asm statements with LLVM of which only
> one is eliminated. This optimisation origins in commit ca4256348660c
> ("x86/percpu: Use C for percpu read/write accessors").
>
> __seg_fs and __seg_gs is supported by LLVM but enabling it leads to tons
> warnings and aborts later.

Tons of warnings is just due to clang being picky and warns for
duplicated qualifiers, such as "__seg_gs __seg_gs var". This can be
fixed with:

https://lore.kernel.org/lkml/20240526175655.227798-1-ubizjak@xxxxxxxxx/

> Is there something missing in LLVM? The generated code for
> raw_cpu_read_long(this_cpu_off) looks fine.

Yes:

1. The %fs: and %gs: prefix does not get emitted in inline assembly.

2. An internal compiler error when addressing symbols directly:
https://github.com/llvm/llvm-project/issues/93449

3. Wrong named address space for anonymous struct:
https://github.com/llvm/llvm-project/issues/119705

Uros.