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