From: Jens Axboe <axboe@kernel.dk>
To: Ming Lei <ming.lei@canonical.com>, Jens Axboe <axboe@fb.com>,
linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>,
Mike Snitzer <snitzer@redhat.com>,
"open list:XFS FILESYSTEM" <xfs@oss.sgi.com>,
linux-block@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
Shaohua Li <shli@fb.com>, Tejun Heo <tj@kernel.org>,
Keith Busch <keith.busch@intel.com>,
Kent Overstreet <kent.overstreet@gmail.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"open list:DRBD DRIVER" <drbd-dev@lists.linbit.com>
Subject: Re: [PATCH v4 0/8] block: prepare for multipage bvecs
Date: Thu, 14 Apr 2016 08:11:03 -0600 [thread overview]
Message-ID: <570FA4F7.6020301@kernel.dk> (raw)
In-Reply-To: <1460634438-26530-1-git-send-email-ming.lei@canonical.com>
On 04/14/2016 05:46 AM, Ming Lei wrote:
> Hi,
>
> Interests[1] have been shown in multipage bvecs, so this patchset
> try to prepare for the support and do two things:
>
> 1) the 1st 4 patches use bvec iterator to implement iterate_bvec(),
> then we can drop the non-standard way for iterating bvec, which
> can be thought as a good cleanup for lib/iov_iter.c
>
> 2) remove BIO_MAX_SECTORS & BIO_MAX_SIZE, and now there is only
> one user for each. Once multipage bvecs is introduced, one bio
> may hold lots of sectors, and we should always use sort of BIO_MAX_VECS
> which should be introduced in future and is similiar with current
> BIO_MAX_PAGES.
>
> xfstests(-a auto) have been run over ext4/xfs and no regression found
> by this patchset.
We've had too many disasters in the block layer the last few series, I'm
making the 4.7 round a nice and small one. I don't mind taking prep
patches for the multipage bvecs, if they are simple and clean, but
that's about the extent of it.
Just a heads up.
--
Jens Axboe
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Ming Lei <ming.lei@canonical.com>, Jens Axboe <axboe@fb.com>,
linux-kernel@vger.kernel.org
Cc: Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>,
Mike Snitzer <snitzer@redhat.com>,
"open list:XFS FILESYSTEM" <xfs@oss.sgi.com>,
linux-block@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
Shaohua Li <shli@fb.com>, Tejun Heo <tj@kernel.org>,
Keith Busch <keith.busch@intel.com>,
Kent Overstreet <kent.overstreet@gmail.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"open list:DRBD DRIVER" <drbd-dev@lists.linbit.com>
Subject: Re: [Drbd-dev] [PATCH v4 0/8] block: prepare for multipage bvecs
Date: Thu, 14 Apr 2016 08:11:03 -0600 [thread overview]
Message-ID: <570FA4F7.6020301@kernel.dk> (raw)
In-Reply-To: <1460634438-26530-1-git-send-email-ming.lei@canonical.com>
On 04/14/2016 05:46 AM, Ming Lei wrote:
> Hi,
>
> Interests[1] have been shown in multipage bvecs, so this patchset
> try to prepare for the support and do two things:
>
> 1) the 1st 4 patches use bvec iterator to implement iterate_bvec(),
> then we can drop the non-standard way for iterating bvec, which
> can be thought as a good cleanup for lib/iov_iter.c
>
> 2) remove BIO_MAX_SECTORS & BIO_MAX_SIZE, and now there is only
> one user for each. Once multipage bvecs is introduced, one bio
> may hold lots of sectors, and we should always use sort of BIO_MAX_VECS
> which should be introduced in future and is similiar with current
> BIO_MAX_PAGES.
>
> xfstests(-a auto) have been run over ext4/xfs and no regression found
> by this patchset.
We've had too many disasters in the block layer the last few series, I'm
making the 4.7 round a nice and small one. I don't mind taking prep
patches for the multipage bvecs, if they are simple and clean, but
that's about the extent of it.
Just a heads up.
--
Jens Axboe
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Ming Lei <ming.lei@canonical.com>, Jens Axboe <axboe@fb.com>,
linux-kernel@vger.kernel.org
Cc: linux-block@vger.kernel.org,
Christoph Hellwig <hch@infradead.org>,
Al Viro <viro@zeniv.linux.org.uk>,
"open list:DRBD DRIVER" <drbd-dev@lists.linbit.com>,
Jan Kara <jack@suse.cz>, Keith Busch <keith.busch@intel.com>,
Kent Overstreet <kent.overstreet@gmail.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Mike Snitzer <snitzer@redhat.com>, Shaohua Li <shli@fb.com>,
Tejun Heo <tj@kernel.org>,
"open list:XFS FILESYSTEM" <xfs@oss.sgi.com>
Subject: Re: [PATCH v4 0/8] block: prepare for multipage bvecs
Date: Thu, 14 Apr 2016 08:11:03 -0600 [thread overview]
Message-ID: <570FA4F7.6020301@kernel.dk> (raw)
In-Reply-To: <1460634438-26530-1-git-send-email-ming.lei@canonical.com>
On 04/14/2016 05:46 AM, Ming Lei wrote:
> Hi,
>
> Interests[1] have been shown in multipage bvecs, so this patchset
> try to prepare for the support and do two things:
>
> 1) the 1st 4 patches use bvec iterator to implement iterate_bvec(),
> then we can drop the non-standard way for iterating bvec, which
> can be thought as a good cleanup for lib/iov_iter.c
>
> 2) remove BIO_MAX_SECTORS & BIO_MAX_SIZE, and now there is only
> one user for each. Once multipage bvecs is introduced, one bio
> may hold lots of sectors, and we should always use sort of BIO_MAX_VECS
> which should be introduced in future and is similiar with current
> BIO_MAX_PAGES.
>
> xfstests(-a auto) have been run over ext4/xfs and no regression found
> by this patchset.
We've had too many disasters in the block layer the last few series, I'm
making the 4.7 round a nice and small one. I don't mind taking prep
patches for the multipage bvecs, if they are simple and clean, but
that's about the extent of it.
Just a heads up.
--
Jens Axboe
next prev parent reply other threads:[~2016-04-14 14:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-14 11:46 [PATCH v4 0/8] block: prepare for multipage bvecs Ming Lei
2016-04-14 11:46 ` Ming Lei
2016-04-14 11:46 ` [PATCH v4 1/8] block: move bvec iterator into include/linux/bvec.h Ming Lei
2016-04-14 11:46 ` [PATCH v4 2/8] block: move two bvec structure into bvec.h Ming Lei
2016-04-14 11:46 ` [PATCH v4 3/8] block: mark 1st parameter of bvec_iter_advance as const Ming Lei
2016-04-14 11:46 ` [PATCH v4 4/8] iov_iter: use bvec iterator to implement iterate_bvec() Ming Lei
2016-04-14 11:46 ` [PATCH v4 5/8] fs: xfs: replace BIO_MAX_SECTORS with BIO_MAX_PAGES Ming Lei
2016-04-14 11:46 ` Ming Lei
2016-04-14 11:46 ` [PATCH v4 6/8] block: bio: remove BIO_MAX_SECTORS Ming Lei
2016-04-14 11:47 ` [PATCH v4 7/8] block: drbd: avoid to use BIO_MAX_SIZE Ming Lei
2016-04-14 11:47 ` [PATCH v4 8/8] block: bio: remove BIO_MAX_SIZE Ming Lei
2016-04-14 14:11 ` Jens Axboe [this message]
2016-04-14 14:11 ` [PATCH v4 0/8] block: prepare for multipage bvecs Jens Axboe
2016-04-14 14:11 ` [Drbd-dev] " Jens Axboe
2016-04-14 22:22 ` Ming Lei
2016-04-14 22:22 ` Ming Lei
2016-04-14 22:22 ` [Drbd-dev] " Ming Lei
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=570FA4F7.6020301@kernel.dk \
--to=axboe@kernel.dk \
--cc=axboe@fb.com \
--cc=drbd-dev@lists.linbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=keith.busch@intel.com \
--cc=kent.overstreet@gmail.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=shli@fb.com \
--cc=snitzer@redhat.com \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=xfs@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.