From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:45752 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758393AbcB1Qpt (ORCPT ); Sun, 28 Feb 2016 11:45:49 -0500 Message-ID: <1456677946.2324.9.camel@HansenPartnership.com> Subject: Re: [Lsf-pc] [LSF/MM ATTEND] block: multipage bvecs From: James Bottomley To: Christoph Hellwig Cc: Ming Lei , Linux FS Devel , linux-block@vger.kernel.org, lsf-pc@lists.linuxfoundation.org Date: Sun, 28 Feb 2016 08:45:46 -0800 In-Reply-To: <20160228162933.GA16019@infradead.org> References: <20160228160716.GA12881@infradead.org> <1456676806.2324.4.camel@HansenPartnership.com> <20160228162933.GA16019@infradead.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, 2016-02-28 at 08:29 -0800, Christoph Hellwig wrote: > On Sun, Feb 28, 2016 at 08:26:46AM -0800, James Bottomley wrote: > > You mean in bio_add_page() the code which currently aggregates > > chunks within a page could build a bio vec entry up to the max > > segment size? I think that is reasonable, especially now the bio > > splitting code can actually split inside a bio vec entry. > > Yes. Kent has an old prototype that did this at: > > https://evilpiepirate.org/git/linux-bcache.git/log/?h=block_stuff > > I don't think any of that is reusable as-is, but the basic idea is > sounds and very useful. The basic idea, yes, but the actual code in that tree would still have built up bv entries that are too big. We have to thread bio_add_page() with knowledge of the queue limits, which is somewhat hard since they're deliberately queue agnostic. Perhaps some global minimum queue segment size would work? James