From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only) Date: Fri, 27 Mar 2015 01:12:43 -0700 Message-ID: <20150327081243.GA26453@infradead.org> References: <20150326202824.65d03787.akpm@linux-foundation.org> <20150326230833.4ccfaebb.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org To: Volker Lendecke Cc: Andrew Morton , Milosz Tanski , linux-kernel@vger.kernel.org, Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman , Tejun Heo , Jeff Moyer , Theodore Ts'o , Al Viro , linux-api@vger.kernel.org, Michael Kerrisk , linux-arch@vger.kernel.org, Dave Chinner List-Id: linux-arch.vger.kernel.org On Fri, Mar 27, 2015 at 09:02:51AM +0100, Volker Lendecke wrote: > No, this is not the case. Maybe my whole understanding of > pread is wrong: I always thought that it won't return short > if the file spans the pread range. EINTR nonwithstanding. Per Posix it could, however if we do it for regular file reads hell will break lose because no one expects it. So in practice it can't. > > > if (it's all in cache) > > I know I'm repeating myself: We have a race condition here. > A small one, but it is racy. I've seen loaded systems where > we spend seconds between becoming re-scheduled. In these > systems, it will be the norm to block in later reads. And we > don't have a good way to detect this situation afterwards > and turn to threads as a precaution next time. Exactly. One that matters in real life, too. Nevermind that preadv2 is a way cleaner interface than fincore. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.9]:51956 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753201AbbC0IMt (ORCPT ); Fri, 27 Mar 2015 04:12:49 -0400 Date: Fri, 27 Mar 2015 01:12:43 -0700 From: Christoph Hellwig Subject: Re: [PATCH v7 0/5] vfs: Non-blockling buffered fs read (page cache only) Message-ID: <20150327081243.GA26453@infradead.org> References: <20150326202824.65d03787.akpm@linux-foundation.org> <20150326230833.4ccfaebb.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Volker Lendecke Cc: Andrew Morton , Milosz Tanski , linux-kernel@vger.kernel.org, Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, Mel Gorman , Tejun Heo , Jeff Moyer , Theodore Ts'o , Al Viro , linux-api@vger.kernel.org, Michael Kerrisk , linux-arch@vger.kernel.org, Dave Chinner Message-ID: <20150327081243.1Bbob-oPNWed0UwDwwaUdJZ8jKnTU62i0-fiHdkAUP0@z> On Fri, Mar 27, 2015 at 09:02:51AM +0100, Volker Lendecke wrote: > No, this is not the case. Maybe my whole understanding of > pread is wrong: I always thought that it won't return short > if the file spans the pread range. EINTR nonwithstanding. Per Posix it could, however if we do it for regular file reads hell will break lose because no one expects it. So in practice it can't. > > > if (it's all in cache) > > I know I'm repeating myself: We have a race condition here. > A small one, but it is racy. I've seen loaded systems where > we spend seconds between becoming re-scheduled. In these > systems, it will be the norm to block in later reads. And we > don't have a good way to detect this situation afterwards > and turn to threads as a precaution next time. Exactly. One that matters in real life, too. Nevermind that preadv2 is a way cleaner interface than fincore.