From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:45468 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757489AbcB1QBY (ORCPT ); Sun, 28 Feb 2016 11:01:24 -0500 Message-ID: <1456675282.2324.2.camel@HansenPartnership.com> Subject: Re: [Lsf-pc] [LSF/MM ATTEND] block: multipage bvecs From: James Bottomley To: Boaz Harrosh , Ming Lei , lsf-pc@lists.linuxfoundation.org Cc: linux-block@vger.kernel.org, Linux FS Devel Date: Sun, 28 Feb 2016 08:01:22 -0800 In-Reply-To: <56D2D757.2000204@plexistor.com> References: <56D2D757.2000204@plexistor.com> 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 13:17 +0200, Boaz Harrosh wrote: > On 02/26/2016 06:33 PM, Ming Lei wrote: > > Hi, > > > > I'd like to participate in LSF/MM and discuss multipage bvecs. > > > > Kent posted the idea[1] before, but never pushed out. > > I have studied multipage bvecs for a while, and think > > it is a good idea to improve block subsystem. > > > > Multipage bvecs means that one 'struct bio_bvec' can hold > > multiple pages which are physically contiguous instead > > of one single page used in current kernel. > > > > Hi Ming Lei > > This is an interesting talk for me. > > I don't know if you ever tried it but I did. If I take a regular > SSD disk or a PCIE flash card that I have in my machine and > I stick a pointer to a page and bv_len = PAGE_SIZE * 8 and call > submit_bio, I get 8 pages worth of IO with a single bvec and it > all just works. No it wouldn't. There's no check anywhere that a single bv entry is under the queue max segment size because the assumption is bv_len <= page size. If you start sending multi-page single bio vec entries, you'll violate those assumptions and eventually get an unmappable bio. James