Re: [Linux-ia64] [patch] 2.4.20-ia64-021210 new spinlock code

Keith Owens
2003-03-28T01:39:14Z

On Thu, 27 Mar 2003 15:32:52 -0800,
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Fri, 28 Mar 2003 10:15:02 +1100, Keith Owens <kaos@sgi.com> said:
>
> Keith> The code does not rely on any implementation specific
> Keith> behaviour. Stating that ar.pfs is zero is well defined, it
> Keith> means that the caller (rp in r28) of this code has no frame.
>
>No, an unwinder might check whether a stacked register is out of the
>current frame and complain if so. Ergo, it's implementation-dependent
>behavior.

The only unwinder I care about is in the kernel and that handles this
condition. libunwind also accepts this condition. Both unwinders
check that the stacked register is within the current backing store,
not within the current frame. You are rejecting working, faster and
better debugging code because some hypothetical unwinder might detect
an error one day. Even if this hypothetical unwinder did detect an
error, it would simply stop the unwind.

>Want to guess why the NEW_LOCK code was never enabled? If you want to
>add the code with an #if 0, that's fine with me.

The new spinlock code is faster, shrinks the kernel, allows for
exponential backoff and better debugging. It should be the default in
all kernels, with an option to disable it for people with strange
unwinders.

Disable out of line spinlock code
CONFIG_IA64_DISABLE_OOL_SPINLOCK
By default, IA64 uses out of line code for the spinlock contention
path. This shrinks the size of the kernel, makes uncontended locks
faster and allows for exponential backoff and debugging on contended
locks.

It uses an unusual unwind mechanism that may not work if you use an
unwinder other than the one in the kernel. Even if your unwinder
does not work, the only effect will be an incomplete unwind for code
that is stuck in the spinlock contention path, this has no effect on
the kernel itself.

If you know that you have an IA64 unwinder that cannot cope with the
out of line spinlock code, say Y and live with a kernel that is
larger, slower and cannot debug hung spinlocks. Otherwise say N.

Acceptable?