On Tue, 4 Jun 2013 10:53:22 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Tue, Jun 04, 2013 at 07:46:40AM -0700, Christoph Hellwig wrote: > > Having RCU for modification mostly workloads never is a good idea, so > > I don't think it makes sense to mention it here. > > > > If you care about the overhead it's worth trying to use per-cpu lists, > > though. > > Yes. The lock and unlock could happen on different CPU's--but I think > you can make the rule that the lock stays associated with the list it > was first put on, and then it's correct in general and hopefully quick > in the common case. > It's important to distinguish between the blocked_list/hash and the file_lock_list. Yes, they use the same embedded list_head or hlist_node in the file_lock, but they have very different characteristics and use cases. In the testing I did, having a hashtable for the blocked locks helped a lot more than a percpu list. The trick with deadlock detection is to ensure that you don't spend a lot of time walking the lists. Since we do deadlock detection frequently, we need to optimize for that case. For the file_lock_list, it might make sense to have percpu hlists with an lglock however. The thing to note here is that the file_lock_list is almost never read. Only /proc/locks uses it, so anything we can do to optimize the list manipulation is probably worth it. All that said, I'm leery about changing too much of this code too fast. It's pretty old and poorly understood, so I think we need to be cautious and take an incremental approach to changing it. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
