From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753745AbbC3Uce (ORCPT ); Mon, 30 Mar 2015 16:32:34 -0400 Received: from fn.samba.org ([216.83.154.106]:42435 "EHLO mail.samba.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753582AbbC3Ucb (ORCPT ); Mon, 30 Mar 2015 16:32:31 -0400 Date: Mon, 30 Mar 2015 13:32:27 -0700 From: Jeremy Allison To: Andrew Morton Cc: Christoph Hellwig , Jeremy Allison , Milosz Tanski , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman , Volker Lendecke , Tejun Heo , Jeff Moyer , "Theodore Ts'o" , Al Viro , linux-api@vger.kernel.org, Michael Kerrisk , linux-arch@vger.kernel.org, Dave Chinner Subject: Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only) Message-ID: <20150330203227.GA4987@samba2> Reply-To: Jeremy Allison References: <20150326202824.65d03787.akpm@linux-foundation.org> <20150327081822.GA28669@infradead.org> <20150327013516.8c6788be.akpm@linux-foundation.org> <20150327084833.GA7689@infradead.org> <20150327020159.eadd0ce1.akpm@linux-foundation.org> <20150327155854.GA5548@samba2> <20150330073604.GB22229@infradead.org> <20150330132625.52b1250527ca3dcda79e349e@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150330132625.52b1250527ca3dcda79e349e@linux-foundation.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 30, 2015 at 01:26:25PM -0700, Andrew Morton wrote: > > cons: > > d) fincore() is more expensive > > e) fincore() will very occasionally block The above is the killer for Samba. If fincore returns true but when we schedule the pread we block, we're hosed. Once we block, we're done serving clients on the main thread until this returns. That can cause unpredictable response times which can cause client timeouts. A fincore+pread solution that blocks is simply unsafe to use for us. We'll have to stay with the threadpool :-(. > And I don't believe that e) will be a problem in the real world. It's > a significant increase in worst-case latency and a negligible increase > in average latency. I've asked at least three times for someone to > explain why this is unacceptable and no explanation has been provided. See above.