Re: [PATCH 4/8] bio: actually inline inline bvecs into bio

[Jens Axboe]

On Wed, Apr 01 2009, Tejun Heo wrote:
> Jens Axboe wrote:
> > On Wed, Apr 01 2009, Tejun Heo wrote:
> >> Impact: cleanup
> >>
> >> BIO_INLINE_VECS bvecs are inlined into bio to avoid bvec allocation
> >> for small transfers.  This was achieved by declaring zero sized bvec
> >> array at the end of bio and allocating bio with extra bytes at the
> >> end.  As BIO_INLINE_VECS is constant, there is no reason to do this
> >> allocation trick.  This patch simply defines BIO_INLINE_VECS sized
> >> bvec array at the end.  This will help fixing bio_kmalloc().
> > 
> > I don't like this, it's much nicer to do it with a zero sized array. If
> > you don't need a bio_vec, then you don't consume the extra space. I
> > guess for that to really work, we'd need one more slab and mempool
> > though. At least for non-stack bio's. I also fear that direct uses of
> > ->bi_inline_vecs[] will then crop up, making it harder to go back.
> 
> I don't know.  None of the current users cares about it and unless
> there's plan to make the number of inlined vecs variable, doing it
> separately doesn't buy much and I think we'll probably pay more by
> having extra slab and mempool.
> 
> Dropping this one isn't difficult tho.  If your objection is strong,
> I'll drop it and update the next one accordingly.  Actually, what we
> can do for bio_kmalloc() is to embed whole bvec as we know the size
> anyway.

Should not be hard, it's just a matter of what size to pass. Thanks!

-- 
Jens Axboe

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