Re: IGMP and rwlock: Dead ocurred again on TILEPro

On Fri, Feb 18, 2011 at 7:18 AM, Chris Metcalf [off-list ref] wrote:

On 2/17/2011 6:11 PM, David Miller wrote:

quoted

From: Chris Metcalf <redacted>
Date: Thu, 17 Feb 2011 18:04:13 -0500

quoted

On 2/17/2011 5:53 PM, David Miller wrote:

quoted

From: Chris Metcalf <redacted>
Date: Thu, 17 Feb 2011 17:49:46 -0500

quoted

The fix is to disable interrupts for the arch_read_lock family of methods.

How does that help handle the race when it happens between different
cpus, instead of between IRQ and non-IRQ context on the same CPU?

There's no race in that case, since the lock code properly backs off and
retries until the other cpu frees it.  The distinction here is that the
non-IRQ context is "wedged" by the IRQ context.

quoted

Why don't you just use the generic spinlock based rwlock code on Tile,
since that is all that your atomic instructions can handle
sufficiently?

The tile-specific code encodes reader/writer information in the same 32-bit
word that the test-and-set instruction manipulates, so it's more efficient
both in space and time.  This may not really matter for rwlocks, since no
one cares much about them any more, but that was the motivation.

Ok, but IRQ disabling is going to be very expensive.

The interrupt architecture on Tile allows a write to a special-purpose
register to put you into a "critical section" where no interrupts or faults
are delivered.  So we just need to bracket the read_lock operations with
two SPR writes; each takes six machine cycles, so we're only adding 12
cycles to the total cost of taking or releasing a read lock on an rwlock.

--
Chris Metcalf, Tilera Corp.
http://www.tilera.com

Adding that to SPR writes should be fine, but it may cause interrupt
delay a little more that other platform's read_lock()?

Another question: What NMI in the former mail means?

Looking forward to your patch.

Regards

-- 
Cyberman Wu