Re: [PATCH] x86: Drop KGDB support

[David Laight <david.laight.linux@gmail.com>]

On Thu, 29 Oct 2026 10:32:58 -0500
Steve Wahl <steve.wahl@hpe.com> wrote:

> On Thu, Oct 29, 2026 at 10:51:21AM +0000, David Laight wrote:
> > On Wed, 28 Oct 2026 14:58:12 -0500
> > Steve Wahl <steve.wahl@hpe.com> wrote:
> >   
> > > On Wed, Oct 28, 2026 at 08:10:54AM -0700, Dave Hansen wrote:  
> > ...  
> > > 
> > > For an example, I recently used this method to discover that at
> > > least one version of Intel's MPI library likes to read up
> > > /proc/kallsyms from each of the processes it starts, and somewhere
> > > north of 1000's of processors the atomic increment on opening
> > > kallsyms, implemented with a compare-exchange, becomes a hot lock
> > > and initialization that takes little time on a smaller number of
> > > processors, suddenly balloons to half an hour.  
> > 
> > I'm guessing that was pre-ARMv8.1 ??  
> 
> x86, not arm.  And it was on a distro kernel, I didn't check the
> current community kernel because it was a situation where it was
> enough to understand what's going on in the distro kernel, and avoid
> the behavior in the application. 

x86 shouldn't have an exponential issue with cas.
Something else must have been going on.

David

> 
> > The LL/SC retry loops for atomics are completely broken for contended
> > operations.
> > The kernel needs to patch them to use the LSE (single instruction
> > atomics) for ARMv8.1 which guarantee that some progress is made.
> > A CAS loop can still get starved on a single CPU, but some CPU
> > do proceed.
> > You really don't want to use LL/LC on a system with hraair CPU.
> > 
> > One CPU (not arm) that implements LL/SC locks the cache line for a
> > few clocks after LL to give a reasonable chance of the associated SC
> > actually succeeding before the cache line is 'stolen' by another CPU
> > doing an LL.  
> 
> Thanks,
> 
> --> Steve  
>