From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f52.google.com ([74.125.82.52]:33647 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751737AbcB2Jlb (ORCPT ); Mon, 29 Feb 2016 04:41:31 -0500 Received: by mail-wm0-f52.google.com with SMTP id l68so28333205wml.0 for ; Mon, 29 Feb 2016 01:41:30 -0800 (PST) Message-ID: <56D41247.9040402@plexistor.com> Date: Mon, 29 Feb 2016 11:41:27 +0200 From: Boaz Harrosh MIME-Version: 1.0 To: James Bottomley , Ming Lei , lsf-pc@lists.linuxfoundation.org CC: linux-block@vger.kernel.org, Linux FS Devel Subject: Re: [Lsf-pc] [LSF/MM ATTEND] block: multipage bvecs References: <56D2D757.2000204@plexistor.com> <1456675282.2324.2.camel@HansenPartnership.com> In-Reply-To: <1456675282.2324.2.camel@HansenPartnership.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 02/28/2016 06:01 PM, James Bottomley wrote: > 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. > I thought so too. Imagine my surprise. But it just works. Limits aside for a second. I followed the code path and everywhere we are using bv_len. so does the sg_map DMA code. And all comes out just fine. So if I'm not crossing any boundaries it works. I'd imagine that any SW driver that actually accesses the page as a page* for say kmap() yes would crash terribly. But the virtual-to-phisical mapping does work (tested 64bit only) . I know big surprise Thanks Boaz > James > >