Re: [PATCH 0/22] Immutable biovecs, block layer changes

[Kent Overstreet]

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