On Tue, Apr 05, 2016 at 11:24:30PM +0800, Ming Lei wrote: > - bio can be embedded into one biger instance, which is often allocated > dynamically, so one extra allocation for bio can be avoided. We can also do this the other way around with the bios front_pad, which avoid the caller poking into bio details. > - we should support arbitrary bio size by this way, at least bio_add_page() > supports this usage. Also code gets lots of simplication with arbitrary bio > size support, such as prio_io(): bcache There is no reason for not supporting huge bios in the core bio code, in fact using bio_kmalloc you can already allocate huges bios dynamically right now. Except that you can't really use it, because the layers below don't expect that. Bios based drivers expect to be able to call bio_clone and friends called on bios passed to them, and might also make assumptions about the max number of bios segments for now. > BTW, the root cause for bcache crash still isn't clear now because > blk_bio_segment_split() should split big bio into proper size with > all queue's limits. Maybe the max segment limit isn't figured out correctly. The root cause is pretty simple: The queue limits matter for request based drivers, which are the only ones getting bios > BIO_MAX_PAGES except for the buggy bcache use case. You'll need to either adjust the limit for all bio based drivers to or get rid of that one magic caller not playing by the rules. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
