This patch-set breaks up the global file_list_lock which was found to be a severe contention point under basically any filesystem intensive workload. It has been part of the -rt kernel for some time now and is deemed solid and useful enough to post in its own right. This contention should also occur on the large SMP machines. Feedback would be appreciated, especially with regard to the extra workqueue that was added to flush per cpu lists. Is there an alternative aproach? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [PATCH 0/7] breaking the global file_list_lock
- From: Christoph Hellwig <[email protected]>
- [PATCH 5/7] fs: restore previous sb->s_files iteration semantics
- From: Peter Zijlstra <[email protected]>
- [PATCH 8/7] fs: free_write_pipe() fix
- From: Peter Zijlstra <[email protected]>
- [PATCH 3/7] barrier: a scalable synchonisation barrier
- From: Peter Zijlstra <[email protected]>
- [PATCH 4/7] fs: break the file_list_lock for sb->s_files
- From: Peter Zijlstra <[email protected]>
- [PATCH 6/7] schedule_on_each_cpu_wq()
- From: Peter Zijlstra <[email protected]>
- [PATCH 7/7] fs: fixup filevec_add_drain_all
- From: Peter Zijlstra <[email protected]>
- [PATCH 1/7] lockdep: lock_set_subclass - reset a held locks subclass
- From: Peter Zijlstra <[email protected]>
- Re: [PATCH 0/7] breaking the global file_list_lock
- Prev by Date: [patch] use __u8/__u32 in userspace ioctl defines for I2O
- Next by Date: [PATCH 1/7] lockdep: lock_set_subclass - reset a held locks subclass
- Previous by thread: [patch] use __u8/__u32 in userspace ioctl defines for I2O
- Next by thread: [PATCH 1/7] lockdep: lock_set_subclass - reset a held locks subclass
- Index(es):