[Linux-ia64] ia64_spinlock_contention and NEW_LOCK

[Linux-ia64] ia64_spinlock_contention and NEW_LOCK

[Keith Owens]

2.4.0-test6-ia64-000811 introduced ia64_spinlock_contention and
NEW_LOCK.  AFAICT they have been disabled ever since they were
introduced.  Are there any plans to use this NEW_LOCK code?  I have two
reasons for asking.

(1) If ia64_spinlock_contention is going to be used then it needs
    unwind data, otherwise an interrupt in this code will not get a
    decent backtrace.

(2) To enable kdb and lkcd diagnosis of hung spinlocks, I want the
    contention path to check for a 'enter debugger now!' flag[*].
    Obviously such a test would be better handled in a single
    contention routine instead of being expanded as part of every
    spinlock usage.

[*] I tried DavidM's suggestion of using INIT interrupts to break into
disabled spinlocks.  It works, and with kdb v4.0 you get a decent
backtrace.  However INIT is far too destructive, once INIT has been
sent the cpu is dead.  Barely acceptable for a completely hung machine,
no good if you are just trying to diagnose a problem.

Re: [Linux-ia64] ia64_spinlock_contention and NEW_LOCK

[David Mosberger]

>>>>> On Sat, 08 Mar 2003 00:57:04 +1100, Keith Owens <kaos@sgi.com> said:

  Keith> 2.4.0-test6-ia64-000811 introduced ia64_spinlock_contention
  Keith> and NEW_LOCK.  AFAICT they have been disabled ever since they
  Keith> were introduced.  Are there any plans to use this NEW_LOCK
  Keith> code?

I still think it would make sense to have back-off logic in the
spinlock contention case, but given that I haven't had time to work on
it in the last 2 years and nobody else has expressed interest in it, I
think it's time to just nuke the code.  If someone wants to work on it
later on, it's been archived often enough that the code can be dug out
if necessary.

Thanks for reminding me.

	--david

Re: [Linux-ia64] ia64_spinlock_contention and NEW_LOCK

[Keith Owens]

On Tue, 11 Mar 2003 14:37:23 -0800, 
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Sat, 08 Mar 2003 00:57:04 +1100, Keith Owens <kaos@sgi.com> said:
>
>  Keith> 2.4.0-test6-ia64-000811 introduced ia64_spinlock_contention
>  Keith> and NEW_LOCK.  AFAICT they have been disabled ever since they
>  Keith> were introduced.  Are there any plans to use this NEW_LOCK
>  Keith> code?
>
>I still think it would make sense to have back-off logic in the
>spinlock contention case, but given that I haven't had time to work on
>it in the last 2 years and nobody else has expressed interest in it, I
>think it's time to just nuke the code.  If someone wants to work on it
>later on, it's been archived often enough that the code can be dug out
>if necessary.

Can you remember what was wrong with the out of line contention code?
The obvious problems are the lack of unwind data, it will not work for
spin locks in modules (PCREL21B will not reach from region 5 to region
7) and the fact that ar.pfs gets corrupted (gcc 2.96 does not recognise
that ar.pfs in the clobber list means leaf functions must now save
ar.pfs).  Were there any other problems?

Re: [Linux-ia64] ia64_spinlock_contention and NEW_LOCK

[David Mosberger]

>>>>> On Wed, 12 Mar 2003 12:38:32 +1100, Keith Owens <kaos@sgi.com> said:

  Keith> Can you remember what was wrong with the out of line
  Keith> contention code?  The obvious problems are the lack of unwind
  Keith> data, it will not work for spin locks in modules (PCREL21B
  Keith> will not reach from region 5 to region 7) and the fact that
  Keith> ar.pfs gets corrupted (gcc 2.96 does not recognise that
  Keith> ar.pfs in the clobber list means leaf functions must now save
  Keith> ar.pfs).  Were there any other problems?

You mean: apart from being completely broken, it looks great? ;-)

Seriously though: I think the main problem is trying to do branch to
out-of-line code without the compiler knowing about it.  The main
reason I wanted to do that is to avoid turning leaf routines into
interior routines just because of a spinlock acquisition.

I'd actually much prefer to _reduce_ the amount of assembly code in
spinlock.h and to use the ia64intrin.h builtins instead.  If we tag
the critical expressions with __builtin_expect(), the compiler would
have enough information to do the Right Thing.  In fact, if the
compiler were able to do "shrink-wrapping", it could even avoid
turning leafs into non-leafs (for the uncontended case).  That way,
the back-off algorithm could be implemented as a normal C routine,
which would make everything much nicer.  (Last time I checked, there
were no plans to support shrink-wrapping in GCC, but that may have
changed.  The Intel compiler probably does support it though, but I
don't know whether it honors __builtin_expect()).

	--david