| 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@xxxxxxx> |
| References: | <20060301125320.20FDA49F1681@xxxxxxxxxxxxxxxxxxxxxxx> <200603021309.46495.ak@xxxxxxx> <Pine.LNX.4.64.0603020846080.22647@xxxxxxxxxxx> <200603021852.35443.ak@xxxxxxx> |
| 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
|
| Previous by Date: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, Linus Torvalds |
|---|---|
| Next by Date: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, Andi Kleen |
| Previous by Thread: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, Andi Kleen |
| Next by Thread: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, Andi Kleen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |