linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Overstreet <kmo@daterainc.com>
To: hch@infradead.org, axboe@kernel.dk,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH WIP] Multipage biovecs
Date: Wed, 25 Sep 2013 13:22:38 -0700	[thread overview]
Message-ID: <1380140564-9030-1-git-send-email-kmo@daterainc.com> (raw)

This patch series is most definitely not done yet - I wanted to get it
out so other people could look at where I'm going with it.

It implements multipage biovecs - a single biovec can point to an
arbitrary amount of physically contiguous memory. For code that still
needs to work on individual pages, we add bio_for_each_page() which does
magic to allow iteration over single page bvecs.

This then changes how segment merging works: instead of blk-merge.c
trying to figure out which segments it can merge, we start out by
merging everything that could possibly be merged, and we add
blk_max_segment() which various code can use to find the maximum segment
size, and when building up sglists we split as needed. The end result is
a lot cleaner, IMO.

This patch then deletes bi_seg_front_size and bi_seg_back_size - they're
not needed anymore since the first and last segment size are the lengths
of the biovecs themselves. The patch series does drop segment merging
across bios - my belief is that with the upper layers always building up
the largest bios they can (which is part of what all the immutable
biovec work is intended to help with) that functionality won't be needed
so much anymore - if it still is needed, we can readd it without
bringing back bi_seg_front_size and bi_seg_back_size.

bi_phys_segments can also be deleted now - the only reason this series
doesn't delete it is because the md code is abusing it for other
purposes (I think it's only using it for counting bio splits, which it
could use bi_remaining for instead).

The series is on top of immutable biovecs, and some other stuff not
included here - it's also in my git repository (there's a bunch of other
random crap in that branch though)
git://evilpiepirate.org/~kent/linux-bcache.git block_stuff.

             reply	other threads:[~2013-09-25 20:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-25 20:22 Kent Overstreet [this message]
2013-09-25 20:22 ` [PATCH 1/6] block: Introduce bio_for_each_page() Kent Overstreet
2013-09-25 21:17   ` Zach Brown
2013-09-25 21:49     ` Kent Overstreet
2013-09-25 22:47       ` Zach Brown
2013-09-25 20:22 ` [PATCH 2/6] block: Convert various code to bio_for_each_page() Kent Overstreet
2013-09-25 20:22 ` [PATCH 3/6] Introduce blk_max_segment() Kent Overstreet
2013-09-25 20:22 ` [PATCH 4/6] convert nvme to blk_max_segment() Kent Overstreet
2013-09-25 20:22 ` [PATCH 5/6] convert integrity to new merging Kent Overstreet
2013-09-25 20:22 ` [PATCH 6/6] Multipage bvecs Kent Overstreet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1380140564-9030-1-git-send-email-kmo@daterainc.com \
    --to=kmo@daterainc.com \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).