On Wed, Sep 28, 2011 at 7:00 AM, Jeff Layton <jlayton@xxxxxxxxx> wrote: > On Tue, 27 Sep 2011 16:36:22 -0500 > Steve French <smfrench@xxxxxxxxx> wrote: > >> FYI - The cifs async write in 3.0 seems to exacerbate problems running >> out of memory (apparently) on the Windows 7 system (running as a >> server) after a large file copy to the server completes. I have been >> able to reproduce the same problem on Windows Vista Service Pack 2 >> (which is a good news/bad news story since my earlier testing on >> Windows Vista showed hangs on some requests rather than returning out >> of memory). Does not seem to be a problem with any of the Windows >> server versions just Windows 7 and Vista so far. >> >> As Pavel noted in an earlier note, increasing MaxWorkItems to 4096 in >> the Windows registry solves this. >> >> The cifs async write code does increase large file copy speed >> dramatically (more than 15% in most environments) - but we are working >> through how to handle the Windows7/WindowsVista problem to see if >> there are workarounds. >> > > This is seems likely to be a cifs.ko bug -- it does not respect the > MaxReq parm that the server sends in the negotiate and instead uses a > hardcoded limit of 50 requests (which is tunable via module parm). > > What value is the server sending in the NEGOTIATE? Ensuring that > cifs.ko doesn't exceed that value seems like a worthwhile endeavor. > This is likely to be even worse soon when the async read patches are > merged. Yes, the client should not be exceeding the limit, but more testing is needed of my earlier patch for that. -- Thanks, Steve -- 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
