On Thu, Aug 08, 2013 at 08:09:54AM -0700, Christoph Hellwig wrote: > On Wed, Aug 07, 2013 at 02:54:09PM -0700, Kent Overstreet wrote: > > _However_, I have more patches (that depend on this patch series) to get > > that back - segment merging improvements that get rid of > > bi_seg_front_size, bi_seg_back_size, and bi_phys_segments. Once all that > > is in it should be a net reduction to the size of struct bio. > > What is preventing you from sending those out as well? While it's not > absolutely nessecary it would certainly be good if we'd avoid a struct > bio size regression. There's still some fairly significant changes, and I don't want to make too many invasive changes at once. Main thing is making generic_make_request() take arbitrary size bios. After this series that's just two simple patches, but then the changes to make use of that will be changing behaviour in non obvious ways. The way the merging changes work is it enables multi page bvecs - so a bvec can point to many physically contiguous pages. This moves segment merging to bio_add_page(), and gets rid of bi_phys_segments - now bi_vcnt == bi_phys_segments, we just split the bio if it's too big. Then, with bio_add_page() building up large bios and the block layer splitting them as necessary, there shouldn't be any need for segment merging across bios anymore (because generally when that would've happened before, now we'd just be sending one larger bio down). The remaining patches aren't terribly complicated though (less complicated than this patch series). Trickiest bit is multipage bvecs, and that's mostly just lots of code auditing - the way I convert existing code is by adding bio_for_each_page() - analagous to bio_for_each_segment, but giving you bvecs that point to single pages. So it's an easy conversion, just have to make sure nothing's missed. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
