xfs
[Top] [All Lists]

Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT a

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p
From: Linus Torvalds <torvalds@xxxxxxxx>
Date: Thu, 2 Mar 2006 10:06:50 -0800 (PST)
Cc: David Chinner <dgc@xxxxxxx>, linux-xfs@xxxxxxxxxxx, mingo@xxxxxxx, tony.luck@xxxxxxxxx
In-reply-to: <200603021852.35443.ak@suse.de>
References: <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <200603021309.46495.ak@suse.de> <Pine.LNX.4.64.0603020846080.22647@g5.osdl.org> <200603021852.35443.ak@suse.de>
Sender: linux-xfs-bounce@xxxxxxxxxxx

On Thu, 2 Mar 2006, Andi Kleen wrote:
>
> That would be spinlock nesting of 2 per CPU on a 1024 CPU machine. 
> Not exactly plenty. Better 12-14 at least.

That's PLENTY.

First off, name somebody who sells bigger systems than that.

Second, taking two spinlocks per CPU is crazy in the first place. Who does 
that? Talk about scaling badly.

Third, code that cares can avoid it entirely by just bumping the preempt 
counter _once_, and then using the raw spinlock code. That's how you 
should do it for big-rw-locks anyway, just because it's less insane, if 
that is what XFS is doing with its "two spinlocks per CPU" thing.

Fourth, you ignore the very real possibility that decreasing the size of 
the other fields can cause problems, and you're completely fixated on the 
crazy XFS usage.

                Linus


<Prev in Thread] Current Thread [Next in Thread>