From mboxrd@z Thu Jan 1 00:00:00 1970 From: Evgeniy Polyakov Subject: Re: sendmsg blocking with sendtimeout vs. non-blocking Date: Fri, 24 Oct 2008 19:20:43 +0400 Message-ID: <20081024152043.GB8271@ioremap.net> References: <524f69650810230942s49cc6a20vc642d1314a530175@mail.gmail.com> <20081023140022.679c148f@barsoom.rdu.redhat.com> <524f69650810231219g6802925ajae78765e6cc45a19@mail.gmail.com> <20081023153550.08f13ffe@barsoom.rdu.redhat.com> <524f69650810231240h77cbc88drc50932b1b7ae2e33@mail.gmail.com> <20081023205937.GB19462@ioremap.net> <524f69650810231818m5d31d4acp7f1e7a88aae54641@mail.gmail.com> <20081024013032.GA32749@citi.umich.edu> <20081024125321.GA31851@hmsendeavour.rdu.redhat.com> <20081024135936.GA8365@citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Neil Horman , Steve French , Jeff Layton , Shirish Pargaonkar , Suresh Jayaraman , "linux-cifs-client@lists.samba.org" , linux-fsdevel , Frank S Filz To: Jim Rees Return-path: Received: from intermatrixgroup.ru ([195.178.208.66]:49286 "EHLO tservice.net.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751246AbYJXPUt (ORCPT ); Fri, 24 Oct 2008 11:20:49 -0400 Content-Disposition: inline In-Reply-To: <20081024135936.GA8365@citi.umich.edu> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi. On Fri, Oct 24, 2008 at 09:59:36AM -0400, Jim Rees (rees@umich.edu) wrote: > My explanation may be flawed but the behavior is real. If you turn on > autotuning on the nfsd socket, and don't do anything with the buffer sizes, > nfsd will stall. This is in a 2.6.24 kernel. I would of course welcome > independent verification. That's effectively a problem related to wait for full request to be in the socket queue, which apparently can not grow infinitely and for huge enough request may 'overflow' currently calculated buffer size. I do not know why nfsd decided to only read request from the socket, when it was fully received, probably because it was decided that playing with additional locks (or socket lock itself) to safely demultiplex request is not appropriate and instead system could read it in one kernel_recvmsg() or friend call with own internal locking. Whatever its decision was based on, it does not apply to cifs which reads data in own demultiplexin thread via loops of kernel_recvmsg()s. -- Evgeniy Polyakov