| To: | David Chinner <dgc@xxxxxxx> |
|---|---|
| Subject: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | 02 Mar 2006 05:55:43 +0100 |
| Cc: | linux-xfs@xxxxxxxxxxx |
| In-reply-to: | <20060302030647.GV1174024@melbourne.sgi.com> |
| References: | <20060301125320.20FDA49F1681@chook.melbourne.sgi.com> <p73lkvtzw3e.fsf@verdi.suse.de> <20060302030647.GV1174024@melbourne.sgi.com> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 |
David Chinner <dgc@xxxxxxx> writes: > > However, when we are excluding the counters, we are already running > atomic due to holding the in-core superblock spinlock and the > per-cpu code uses get_cpu()/put_cpu() so neither can get preempted > in the critical sections the spinlocks used to protect. So the only > considerations are having an atomic exclusion mechanism and a wait > method that does not sleep. spinlocks are should be fine for this in theory. All CPUs spinning on a spinlock shouldn't happen normally, but it is supposed to work correctly if it happens. If preemptible spinlocks don't scale to this for large NR_CPUs they're broken and need to be fixed. You discovered a important limitation in them and now instead of fixing them properly you're trying to work around it. Please try to see the big picture a bit more instead of just XFS. -Andi |
| Previous by Date: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, David Chinner |
|---|---|
| Next by Date: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, David Chinner |
| Previous by Thread: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, David Chinner |
| Next by Thread: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, David Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |