On Wed, Nov 16, 2016 at 09:09:17AM -0700, Jens Axboe wrote:
> Another idea - just limit the max we can support in the simplified
> version as a single bio. If the user is requesting more, fall back to
> the old slow path. Doesn't really matter, since the transfer size will
> be large enough to hopefully overcome any deficiencies in the old path.
I really want to kill off the old code :) Maybe we could use my
iomap-based code instead of another block version if we delegate it
far enough away from the host path with a patch like yours, but I really
wonder if avoiding the atomic inc/dec is that important once we are
above a minimal threshold. That being said I think we could avoid
the atomic op for the the single-bio cases even with code that handles
multiples bios. Kent actually noted that on my full blown iomap
version.
But if we need another fast but not super fast case your patch below
looks reasonable. Although we really need to implement O_SYNC/O_DSYNC
support for it to avoid losing data.
> + /*
> + * Overload bio size in error. If it gets set, we lose the
> + * size, but we don't need the size for that case. IO is limited
> + * to BIO_MAX_PAGES, so we can't overflow.
> + */
> + ret = bio->bi_error = bio->bi_iter.bi_size;
Oh, that's a neat trick.
> + if (nr_pages <= DIO_INLINE_BIO_VECS)
> + vecs = inline_vecs;
> + else {
> + vecs = kmalloc(nr_pages * sizeof(struct bio_vec), GFP_KERNEL);
kmalloc_array?
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
