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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
