On Mon, Nov 14 2016, Christoph Hellwig wrote: > On Mon, Nov 14, 2016 at 10:03:20AM +1100, NeilBrown wrote: >> I would suggest adding a "bi_dev_private" field to the bio which is for >> use by the lowest-level driver (much as bi_private is for use by the >> top-level initiator). >> That could be in a union with any or all of: >> unsigned int bi_phys_segments; >> unsigned int bi_seg_front_size; >> unsigned int bi_seg_back_size; >> >> (any driver that needs those, would see a 'request' rather than a 'bio' >> and so could use rq->special) >> >> raid5.c could then use bi_dev_private (or bi_special, or whatever it is call). > > All the three above fields are those that could go away with a full > implementation of the multipage bvec scheme. So any field for driver > use would still be be overhead. If it's just for raid5 it could > be a smaller 16 bit (or maybe even just 8 bit) one. We currently store 2 counters in that field, and before commit 5b99c2ffa980528a197f26 one of the fields was only 8 bits, and that caused problems We could possibly use __bi_remaining in place of raid5_X_bi_active_stripes(). It wouldn't be a completely straightforward conversion, but I think it could be made to work. We *might* be able to use bvec_iter_advance() in place of raid5_bi_processed_stripes(). A careful audit of the code would be needed to be certain. NeilBrown
Attachment:
signature.asc
Description: PGP signature
