From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve French Subject: Re: Kernel 3.0: Instant kernel crash when mounting CIFS (also crashes with linux-3.1-rc2 Date: Fri, 26 Aug 2011 18:05:55 -0500 Message-ID: References: <3300.1313637592@jrobl> <20110818091140.385a9455@barsoom.rdu.redhat.com> <20110818130408.71c55b96@barsoom.rdu.redhat.com> <20110818145257.035a38e9@barsoom.rdu.redhat.com> <20110826175940.2830044d@tlielax.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeff Layton , "J. R. Okajima" , Jesper Juhl , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alan Piszcz , Steve French , linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Justin Piszcz Return-path: In-Reply-To: Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On Fri, Aug 26, 2011 at 5:57 PM, Justin Piszcz wrote: > > > On Fri, 26 Aug 2011, Jeff Layton wrote: > >> On Thu, 18 Aug 2011 14:52:57 -0400 >> Jeff Layton wrote: >> >>> On Thu, 18 Aug 2011 14:18:15 -0400 (EDT) >>> Justin Piszcz wrote: >>> >>>> >>> Like I said, read performance with cifs.ko just plain sucks currently. >>> >>> Don't look for cifs.ko to achieve anywhere near NFS' performance unless >>> you jump through some very odd hoops (like multithreading your workload >>> in userspace, etc). cifs.ko just doesn't do a good job of keeping the >>> pipe "stuffed" as most calls are handled synchronously. A single task >>> can only handle one call on the wire in most cases. The exception here >>> is writes, but that just recently changed... >>> >>> Reads are done using relatively small buffers and then copied to >>> pagecache. Part of what I'm working on will be to allow for much larger >>> reads directly into the pagecache. That should also help performance >>> significantly. >>> >> >> I just posted a patchset that should improve the performance of >> buffered reads. It's rather large but should apply to current upstream >> kernels. If you've had problems with cifs.ko read performance in the >> past, then this would be a good time to step up and help test them. >> >> If it makes things easier, then the patchset is also available via the >> cifs-3.2 branch of my public git tree: >> >> >> http://git.kernel.org/?p=linux/kernel/git/jlayton/linux.git;a=shortlog;h=refs/heads/cifs-3.2 >> >> Thanks, >> -- >> Jeff Layton > > Hi Jeff, > > This was working earlier.. > > # mount -t cifs //10.0.1.1/x /mnt -o user=XXXXXXX,pass=XXXXXXXX > mount error(12): Cannot allocate memory > Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) > > I'll need to contact the owner of the host to see if something has changed > as this _was_ working previously. Fails with Jeff's new 20+ patch series? -- Thanks, Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753022Ab1HZXF5 (ORCPT ); Fri, 26 Aug 2011 19:05:57 -0400 Received: from mail-qw0-f46.google.com ([209.85.216.46]:64914 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751248Ab1HZXF4 (ORCPT ); Fri, 26 Aug 2011 19:05:56 -0400 MIME-Version: 1.0 In-Reply-To: References: <3300.1313637592@jrobl> <20110818091140.385a9455@barsoom.rdu.redhat.com> <20110818130408.71c55b96@barsoom.rdu.redhat.com> <20110818145257.035a38e9@barsoom.rdu.redhat.com> <20110826175940.2830044d@tlielax.poochiereds.net> Date: Fri, 26 Aug 2011 18:05:55 -0500 Message-ID: Subject: Re: Kernel 3.0: Instant kernel crash when mounting CIFS (also crashes with linux-3.1-rc2 From: Steve French To: Justin Piszcz Cc: Jeff Layton , "J. R. Okajima" , Jesper Juhl , linux-kernel@vger.kernel.org, Alan Piszcz , Steve French , linux-cifs@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 26, 2011 at 5:57 PM, Justin Piszcz wrote: > > > On Fri, 26 Aug 2011, Jeff Layton wrote: > >> On Thu, 18 Aug 2011 14:52:57 -0400 >> Jeff Layton wrote: >> >>> On Thu, 18 Aug 2011 14:18:15 -0400 (EDT) >>> Justin Piszcz wrote: >>> >>>> >>> Like I said, read performance with cifs.ko just plain sucks currently. >>> >>> Don't look for cifs.ko to achieve anywhere near NFS' performance unless >>> you jump through some very odd hoops (like multithreading your workload >>> in userspace, etc). cifs.ko just doesn't do a good job of keeping the >>> pipe "stuffed" as most calls are handled synchronously. A single task >>> can only handle one call on the wire in most cases. The exception here >>> is writes, but that just recently changed... >>> >>> Reads are done using relatively small buffers and then copied to >>> pagecache. Part of what I'm working on will be to allow for much larger >>> reads directly into the pagecache. That should also help performance >>> significantly. >>> >> >> I just posted a patchset that should improve the performance of >> buffered reads. It's rather large but should apply to current upstream >> kernels. If you've had problems with cifs.ko read performance in the >> past, then this would be a good time to step up and help test them. >> >> If it makes things easier, then the patchset is also available via the >> cifs-3.2 branch of my public git tree: >> >> >> http://git.kernel.org/?p=linux/kernel/git/jlayton/linux.git;a=shortlog;h=refs/heads/cifs-3.2 >> >> Thanks, >> -- >> Jeff Layton > > Hi Jeff, > > This was working earlier.. > > # mount -t cifs //10.0.1.1/x /mnt -o user=XXXXXXX,pass=XXXXXXXX > mount error(12): Cannot allocate memory > Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) > > I'll need to contact the owner of the host to see if something has changed > as this _was_ working previously. Fails with Jeff's new 20+ patch series? -- Thanks, Steve