Re: [Lsf-pc] [LSF/MM ATTEND] block: multipage bvecs

[Boaz Harrosh <boaz@plexistor.com>]

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
> 
>