Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760255AbYFXMRf (ORCPT ); Tue, 24 Jun 2008 08:17:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759954AbYFXMRV (ORCPT ); Tue, 24 Jun 2008 08:17:21 -0400 Received: from relay.2ka.mipt.ru ([194.85.82.65]:53674 "EHLO 2ka.mipt.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759772AbYFXMRU (ORCPT ); Tue, 24 Jun 2008 08:17:20 -0400 Date: Tue, 24 Jun 2008 16:15:08 +0400 From: Evgeniy Polyakov To: Miklos Szeredi Cc: jens.axboe@oracle.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, torvalds@linux-foundation.org Subject: Re: [rfc patch 3/4] splice: remove confirm from pipe_buf_operations Message-ID: <20080624121508.GB15368@2ka.mipt.ru> References: <20080621154607.154640724@szeredi.hu> <20080621154726.494538562@szeredi.hu> <20080624080440.GJ20851@kernel.dk> <20080624111913.GP20851@kernel.dk> <20080624114654.GA27123@2ka.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1721 Lines: 38 On Tue, Jun 24, 2008 at 02:02:19PM +0200, Miklos Szeredi (miklos@szeredi.hu) wrote: > > Maybe not that great if mark all readahead pages as, well, readahead, > > and do the same for readpage (essnetially it is the same). > > It isn't that easy. Readahead (->readpages()) is best effort, and is > allowed to not bring the page uptodate, since it will be retried with > ->readpage(). I don't know whether any filesystems actually do that, > but it's allowed nonetheless. Yes, there is such filesystem :) It is quite useful for network FS, since it does not bother to wait until pages are in the cache and can try next request. Anyone who scheduled readahead has full control over that pages and is allowed to set/clear whatever flags it want (pages are locked), so it would be a great win to set page as being read and unlocked. It can be a policy to clear read bit when page is evicted from the cache by failed readahead/readpage(s). > > > What's the use case where it matters that splice-in should not block > > > on the read? > > > > To be able to transfer what was already read? > > That needs the consumer to be non-blocking... > > Umm, one more reason why the ->confirm() stuff is currently busted: > pipe_read() will block on such a buffer even if pipe file is marked > O_NONBLOCK. Fixing that would take a hell of a lot of added > complexity in pipe_poll(), etc... Yes, nonblocking splice is tricky and it covers only half of the users. -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/