Re: Horrible regression with -CURRENT from "Don't busy-lock-loop in preemptable spinlocks" patch

From: Chris Wedgwood <cw@f00f.org>
To: Paul Mackerras <paulus@samba.org>
Cc: Andrew Morton <akpm@osdl.org>,
	torvalds@osdl.org, mingo@elte.hu, benh@kernel.crashing.org,
	linux-kernel@vger.kernel.org
Subject: Re: Horrible regression with -CURRENT from "Don't busy-lock-loop in preemptable spinlocks" patch
Date: Mon, 17 Jan 2005 00:00:22 -0800	[thread overview]
Message-ID: <20050117080022.GA4282@taniwha.stupidest.org> (raw)
In-Reply-To: <16875.28257.239324.486966@cargo.ozlabs.ibm.com>

On Mon, Jan 17, 2005 at 06:50:57PM +1100, Paul Mackerras wrote:

> AFAICS on i386 the lock word, although it goes to 0 when write-locked,
> can then go negative temporarily when another cpu tries to get a read
> or write lock.  So I think this should be
> 
> ((signed int)(x)->lock <= 0)

I think you're right, objdump -d shows[1] _write_lock looks
something like:

      lock subl $0x1000000,(%ebx)
      sete   %al
      test   %al,%al
      jne    out;
      lock addl $0x1000000,(%ebx)
  out:

so I guess it 2+ CPUs grab a write-lock at once it would indeed be
less than zero (the initial value is RW_LOCK_BIAS which is 0x1000000
in this case).

> (or the equivalent using atomic_read).

on x86 aligned-reads will be always be atomic AFAIK?

[1] Yes, I'm stupid, trying to grok the twisty-turny-maze of headers
    and what not made my head hurt and objdump -d seemed easier.