On 2/15/19 10:14 AM, Bart Van Assche wrote:
> On Fri, 2019-02-15 at 08:49 -0700, Jens Axboe wrote:
>> On 2/15/19 4:13 AM, Ming Lei wrote:
>>> This patchset brings multi-page bvec into block layer:
>>
>> Applied, thanks Ming. Let's hope it sticks!
>
> Hi Jens and Ming,
>
> Test nvmeof-mp/002
On 2/15/19 5:16 PM, Mike Snitzer wrote:
> On Fri, Feb 15 2019 at 9:33am -0500,
> Nikos Tsironis wrote:
>
>> On 2/15/19 3:54 PM, Joe Thornber wrote:
>>> Ack.
>>>
>>> Thanks for this I was under the mistaken impression that FUA requests got
>>> split
>>> by core dm into separate payload and
On Fri, 2019-02-15 at 08:49 -0700, Jens Axboe wrote:
> On 2/15/19 4:13 AM, Ming Lei wrote:
> > This patchset brings multi-page bvec into block layer:
>
> Applied, thanks Ming. Let's hope it sticks!
Hi Jens and Ming,
Test nvmeof-mp/002 fails with Jens' for-next branch from this morning.
I have
On 2/15/19 4:13 AM, Ming Lei wrote:
> Hi,
>
> This patchset brings multi-page bvec into block layer:
>
> 1) what is multi-page bvec?
>
> Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages
> which are physically contiguous instead of one single page used in linux
> kernel
On Fri, Feb 15 2019 at 9:33am -0500,
Nikos Tsironis wrote:
> On 2/15/19 3:54 PM, Joe Thornber wrote:
> > Ack.
> >
> > Thanks for this I was under the mistaken impression that FUA requests got
> > split
> > by core dm into separate payload and PREFLUSH requests.
> >
> > I've audited dm-cache
I still don't understand why mp_bvec_last_segment isn't simply
called bvec_last_segment as there is no conflict. But I don't
want to hold this series up on that as there only are two users
left and we can always just fix it up later.
--
dm-devel mailing list
dm-devel@redhat.com
Hi Linus,
The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9:
Linux 5.0-rc6 (2019-02-10 14:42:20 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
tags/for-5.0/dm-fixes-3
for you to fetch
On 2/15/19 3:54 PM, Joe Thornber wrote:
> Ack.
>
> Thanks for this I was under the mistaken impression that FUA requests got
> split
> by core dm into separate payload and PREFLUSH requests.
>
> I've audited dm-cache and that looks ok.
>
> How did you test this patch? That missing
On Thu, 14 Feb 2019, Mike Snitzer wrote:
> On Thu, Feb 14 2019 at 11:54am -0500,
> Mikulas Patocka wrote:
>
> > > > x86-64, 2x six-core
> > > > /dev/ram0 2449MiB/s
> > > > /dev/mapper/lin 5.0-rc without optimization 1970MiB/s
> > > > /dev/mapper/lin
Ack.
Thanks for this I was under the mistaken impression that FUA requests got split
by core dm into separate payload and PREFLUSH requests.
I've audited dm-cache and that looks ok.
How did you test this patch? That missing bio_list_init() in V1 must
have caused memory corruption?
- Joe
On
Since bdced438acd83ad83a6c ("block: setup bi_phys_segments after splitting"),
physical segment number is mainly figured out in blk_queue_split() for
fast path, and the flag of BIO_SEG_VALID is set there too.
Now only blk_recount_segments() and blk_recalc_rq_segments() use this
flag.
Basically
QUEUE_FLAG_NO_SG_MERGE has been killed, so kill BLK_MQ_F_SG_MERGE too.
Reviewed-by: Christoph Hellwig
Reviewed-by: Omar Sandoval
Signed-off-by: Ming Lei
---
block/blk-mq-debugfs.c | 1 -
drivers/block/loop.c | 2 +-
drivers/block/nbd.c | 2 +-
drivers/block/rbd.c
Now multi-page bvec is supported, some helpers may return page by
page, meantime some may return segment by segment, this patch
documents the usage.
Reviewed-by: Christoph Hellwig
Reviewed-by: Omar Sandoval
Signed-off-by: Ming Lei
---
Documentation/block/biovecs.txt | 25
Now multi-page bvec can cover CONFIG_THP_SWAP, so we don't need to
increase BIO_MAX_PAGES for it.
CONFIG_THP_SWAP needs to split one THP into normal pages and adds
them all to one bio. With multipage-bvec, it just takes one bvec to
hold them all.
Reviewed-by: Omar Sandoval
Reviewed-by:
This patch pulls the trigger for multi-page bvecs.
Reviewed-by: Omar Sandoval
Signed-off-by: Ming Lei
---
block/bio.c | 22 +++---
fs/iomap.c | 4 ++--
fs/xfs/xfs_aops.c | 4 ++--
include/linux/bio.h | 2 +-
4 files changed, 20 insertions(+), 12
It is more efficient to use bio_for_each_bvec() to map sg, meantime
we have to consider splitting multipage bvec as done in blk_bio_segment_split().
Reviewed-by: Omar Sandoval
Reviewed-by: Christoph Hellwig
Signed-off-by: Ming Lei
---
block/blk-merge.c | 70
This patch introduces one extra iterator variable to bio_for_each_segment_all(),
then we can allow bio_for_each_segment_all() to iterate over multi-page bvec.
Given it is just one mechannical & simple change on all
bio_for_each_segment_all()
users, this patch does tree-wide change in one single
First it is more efficient to use bio_for_each_bvec() in both
blk_bio_segment_split() and __blk_recalc_rq_segments() to compute how
many multi-page bvecs there are in the bio.
Secondly once bio_for_each_bvec() is used, the bvec may need to be
splitted because its length can be very longer than
Preparing for supporting multi-page bvec.
Reviewed-by: Omar Sandoval
Signed-off-by: Ming Lei
---
fs/btrfs/extent_io.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index dc8ba3ee515d..986ef49b0269 100644
---
bch_bio_alloc_pages() is always called on one new bio, so it is safe
to access the bvec table directly. Given it is the only kind of this
case, open code the bvec table access since bio_for_each_segment_all()
will be changed to support for iterating over multipage bvec.
Acked-by: Coly Li
Once multi-page bvec is enabled, the last bvec may include more than one
page, this patch use mp_bvec_last_segment() to truncate the bio.
Reviewed-by: Omar Sandoval
Reviewed-by: Christoph Hellwig
Signed-off-by: Ming Lei
---
fs/buffer.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
iov_iter is implemented on bvec itererator helpers, so it is safe to pass
multi-page bvec to it, and this way is much more efficient than passing one
page in each bvec.
Reviewed-by: Christoph Hellwig
Reviewed-by: Omar Sandoval
Signed-off-by: Ming Lei
---
drivers/block/loop.c | 20
BTRFS and guard_bio_eod() need to get the last singlepage segment
from one multipage bvec, so introduce this helper to make them happy.
Reviewed-by: Omar Sandoval
Signed-off-by: Ming Lei
---
include/linux/bvec.h | 22 ++
1 file changed, 22 insertions(+)
diff --git
bio_for_each_bvec() is used for iterating over multi-page bvec for bio
split & merge code.
rq_for_each_bvec() can be used for drivers which may handle the
multi-page bvec directly, so far loop is one perfect use case.
Reviewed-by: Christoph Hellwig
Reviewed-by: Omar Sandoval
Signed-off-by:
Commit 7759eb23fd980 ("block: remove bio_rewind_iter()") removes
bio_rewind_iter(), then no one uses bvec_iter_rewind() any more,
so remove it.
Reviewed-by: Omar Sandoval
Reviewed-by: Christoph Hellwig
Signed-off-by: Ming Lei
---
include/linux/bvec.h | 24
1 file
This patch introduces helpers of 'mp_bvec_iter_*' for multi-page bvec
support.
The introduced helpers treate one bvec as real multi-page segment,
which may include more than one pages.
The existed helpers of bvec_iter_* are interfaces for supporting current
bvec iterator which is thought as
It is wrong to use bio->bi_vcnt to figure out how many segments
there are in the bio even though CLONED flag isn't set on this bio,
because this bio may be splitted or advanced.
So always use bio_segments() in blk_recount_segments(), and it shouldn't
cause any performance loss now because the
From: Christoph Hellwig
bio_readpage_error currently uses bi_vcnt to decide if it is worth
retrying an I/O. But the vector count is mostly an implementation
artifact - it really should figure out if there is more than a
single sector worth retrying. Use bi_size for that and shift by
Hi,
This patchset brings multi-page bvec into block layer:
1) what is multi-page bvec?
Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages
which are physically contiguous instead of one single page used in linux
kernel for long time.
2) why is multi-page bvec introduced?
29 matches
Mail list logo
