On Fri, Sep 26, 2014 at 12:21:06PM -0400, Trond Myklebust wrote: > > On Fri, Sep 26, 2014 at 10:29:34AM -0400, Trond Myklebust wrote: > >> It worries me that we're putting a mutex directly in the writeback > >> path. For small arrays, it might be acceptable, but what if you have a > >> block device with 1000s of disks on the back end? > >> > >> Is there no better way to fix this issue? > > > > Not without getting rid of the rpc_pipefs interface. That is on my > > very long term TODO list, but it will require new userspace support. > > Why is that? rpc_pipefs was designed to be message based, so it should > work quite well in a multi-threaded environment. We certainly don't > use mutexes around the gssd up/downcall, and the only reason for the > mutex in idmapd is to deal with the keyring upcall. Turns out we can't do anything like that with the existing blkmapd ABI. The other callers that support concurrency have some sort of uniqueue identifier embedded in their messages both on the upcall and the downcall, so that the kernel can find the right structure on the downcall side. Because of that I'd like to request inclusion of this patch with a Cc to stable for 3.17. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
