From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [RFC PATCH 0/7] Non-blockling buffered fs read (page cache only) Date: Mon, 22 Sep 2014 09:42:37 -0700 Message-ID: <20140922164237.GA30229@infradead.org> References: <8EC2A7F3-0E25-4054-9863-4488B8ED5C8D@dilger.ca> <94D0CD8314A33A4D9D801C0FE68B402958C81D56@G9W0745.americas.hpqcorp.net> <20140919112147.GA4639@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jeff Moyer , "Elliott, Robert (Server Storage)" , Andreas Dilger , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-aio@kvack.org" , Mel Gorman , Volker Lendecke , Tejun Heo To: Milosz Tanski Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Sep 22, 2014 at 12:32:02PM -0400, Milosz Tanski wrote: > I spent some time thinking about multi-position scatter/gather in > context of this over the weekend. The non-blocking case seams easy, > the implementation I purposed needs an extra loop. Where this gets > hairy is making the non-trivial blocking case work well (as in have > concurrent requests for each of the ranges) in the filesystem code. If > that's the road we're going to go down I have a gut feeling we're > going to get stuck in the same spot(s) as the other non-blocking > buffered r/w attempts from the past. The other thing sis that we have a basically ready, easy to use implementation of flagged I/O (my name for the new syscalls), while S/G I/O will take forever to discuss and is the natual vehicle for other extensions like T10 DIX. I'd like to suggest you consolidate your syscalls down from 4 to 2 as suggestes by overloading the negative offset argument, giving us two more syscalls slows for S/G once it's ready. Note that a sync S/G syscalls should of course also support these flags, although I suspect the primary use cases for S/G I/O would be through the aio machinery.