| To: | Linus Torvalds <torvalds@xxxxxxxx> |
|---|---|
| Subject: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Thu, 2 Mar 2006 18:52:34 +0100 |
| Cc: | David Chinner <dgc@xxxxxxx>, linux-xfs@xxxxxxxxxxx, mingo@xxxxxxx, tony.luck@xxxxxxxxx |
| In-reply-to: | <Pine.LNX.4.64.0603020846080.22647@xxxxxxxxxxx> |
| References: | <20060301125320.20FDA49F1681@xxxxxxxxxxxxxxxxxxxxxxx> <200603021309.46495.ak@xxxxxxx> <Pine.LNX.4.64.0603020846080.22647@xxxxxxxxxxx> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | KMail/1.9.1 |
On Thursday 02 March 2006 17:53, Linus Torvalds wrote: >nything worse. > > > I don't see anything that would rely on the count being positive > > so using the sign bit is probably ok. Hardirq 11 might be a bit > > tight though, so maybe it would be better to move 64bit machines > > to 64bit here. Yes agreed, it just would be a bigger patch probably affecting many architectures. > And yes, I think it may make sense to just use the full 64 bits on a > 64-bit machine. Eventually. Somebody should check what the larger > constants result in, though. > > And not for now, but obviously the 11 bits will run out for even bigger > machines. But for a "let's fix it quickly", adding three bits should be > plenty good enough, no? That would be spinlock nesting of 2 per CPU on a 1024 CPU machine. Not exactly plenty. Better 12-14 at least. -Andi |
| Previous by Date: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, Andi Kleen |
|---|---|
| Next by Date: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, Linus Torvalds |
| Previous by Thread: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, Linus Torvalds |
| Next by Thread: | Re: TAKE 950027 - xfs_icsb_lock_all_counters fails with CONFIG_PREEMPT and >=256p, Linus Torvalds |
| Indexes: | [Date] [Thread] [Top] [All Lists] |