From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Banks Subject: Re: PATCH [NFSd] NFSv3/TCP Date: Fri, 07 May 2004 18:11:00 +1000 Sender: nfs-admin@lists.sourceforge.net Message-ID: <409B4494.5253316B@melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Neil Brown , linux-kernel@vger.kernel.org, Linux NFS Mailing List Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30) id 1BM0Rv-0007zT-6w for nfs@lists.sourceforge.net; Fri, 07 May 2004 01:11:15 -0700 Received: from mtvcafw.sgi.com ([192.48.171.6] helo=omx2.sgi.com) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.30) id 1BM0Ru-0001PC-UX for nfs@lists.sourceforge.net; Fri, 07 May 2004 01:11:14 -0700 To: Oliver Tennert Errors-To: nfs-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Post: List-Help: List-Subscribe: , List-Archive: Oliver Tennert wrote: > > As it does not any changes for say a i386 architecture, Yes, by design. > I cannot see why > after that my lockups should go away. I don't claim any such thing, I was just resending a patch (which is of no use to you) that Neil mentioned had been lost in the shuffle. > Are lockups no known problem at all? Am I the only one experiencing them? > They _definitely_ went away for me with NFSSVC_MAXBLKSIZE equal 32k, even > under high IO pressure. Sure, I believe you, I just have no idea what your problem is. As a general statement of no particular import, I note that going to 32K has a number of other side effects other than the obvious. For streaming reads and writes the call rate goes down by a factor of 4 so you may be not exercising some race condition. Also there may be different code paths through READDIR and READDIR+ code. Now if you had some kind of kernel debugger and could post some more information, like process list and kernel stack traces from the hang, someone (not me) may be able to figure out the real problem that you've hidden by going to 32K. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262361AbUEGILT (ORCPT ); Fri, 7 May 2004 04:11:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262956AbUEGILT (ORCPT ); Fri, 7 May 2004 04:11:19 -0400 Received: from mtvcafw.sgi.com ([192.48.171.6]:34695 "EHLO omx2.sgi.com") by vger.kernel.org with ESMTP id S262361AbUEGILR (ORCPT ); Fri, 7 May 2004 04:11:17 -0400 Message-ID: <409B4494.5253316B@melbourne.sgi.com> Date: Fri, 07 May 2004 18:11:00 +1000 From: Greg Banks Organization: SGI Australian Software Group X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-6mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Oliver Tennert CC: Neil Brown , linux-kernel@vger.kernel.org, Linux NFS Mailing List Subject: Re: PATCH [NFSd] NFSv3/TCP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Oliver Tennert wrote: > > As it does not any changes for say a i386 architecture, Yes, by design. > I cannot see why > after that my lockups should go away. I don't claim any such thing, I was just resending a patch (which is of no use to you) that Neil mentioned had been lost in the shuffle. > Are lockups no known problem at all? Am I the only one experiencing them? > They _definitely_ went away for me with NFSSVC_MAXBLKSIZE equal 32k, even > under high IO pressure. Sure, I believe you, I just have no idea what your problem is. As a general statement of no particular import, I note that going to 32K has a number of other side effects other than the obvious. For streaming reads and writes the call rate goes down by a factor of 4 so you may be not exercising some race condition. Also there may be different code paths through READDIR and READDIR+ code. Now if you had some kind of kernel debugger and could post some more information, like process list and kernel stack traces from the hang, someone (not me) may be able to figure out the real problem that you've hidden by going to 32K. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI.