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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Apr 2009 14:59:17 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	bharrosh@...asas.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/8] bio: actually inline inline bvecs into bio

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/