David Chinner wrote: On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: Dave, Could you have changed the SB_LOCK from a spinlock to a blocking mutex and have achieved a similar effect?
David Chinner wrote: On Fri, Dec 01, 2006 at 09:38:11AM +1100, David Chinner wrote: On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: These changes wouldn't apply cleanly to tot (3 hun
Well, the reason I didn't go down this path in the first place was that typically only one type of counter would need rebalancing at a time (e.g. free blocks or free inodes, but not both at the same
David Chinner wrote: On Fri, Dec 01, 2006 at 07:22:18PM +0000, Lachlan McIlroy wrote: David Chinner wrote: On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: I think the slow path code
Sorry - my bad. The code did not change for UP, so I didn't think to test it. The patch below abstracts the icsb_mutex so that it doesn't get directly referenced by code outside the per-cpu counter c
David Chinner wrote: On Tue, Dec 05, 2006 at 12:46:46PM +0100, Klaus Strebel wrote: Hi guys, just updated my CVS copy from oss.sgi.com ( the linux-2.6-xfs ) and tried to compile ... but your patch fa
No. I didn't abstract the mutex_init and mutex_destroy calls because they are in the init/destroy functions for the icsb subsystem and those functions are #define'd out when HAVE_PERCPU_SB is not def
The existing per-cpu superblock counter code still uses the existing superblock spin lock when we approach ENOSPC for global synchronisation. On larger machines than this code was originally tested o
Could you have changed the SB_LOCK from a spinlock to a blocking mutex and have achieved a similar effect? Has this change had much testing on a large machine? These changes wouldn't apply cleanly t
Sort of - it would still be inefficient and wouldn't help solve the underlying causes of contention. Also, everything else that uses the SB_LOCK would now have a sleep point where there wasn't one pr
I see the problem - the next patch I am going to send out for review which is earlier in my series.... The growfs fix changes the delta parameter to xfs_icsb_modify_counters() from int to int64_t, an
The existing per-cpu superblock counter code still uses the existing superblock spin lock when we approach ENOSPC for global synchronisation. On larger machines than this code was originally tested o
Could you have changed the SB_LOCK from a spinlock to a blocking mutex and have achieved a similar effect? Has this change had much testing on a large machine? These changes wouldn't apply cleanly t