Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1511585 > unrolled thread

[PATCH 23/60] block: introduce flag QUEUE_FLAG_NO_MP

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 23/60] block: introduce flag QUEUE_FLAG_NO_MP Ming Lei <tom.leiming@gmail.com> - 2016-10-29 10:30 +0200
    Re: [PATCH 23/60] block: introduce flag QUEUE_FLAG_NO_MP Christoph Hellwig <hch@infradead.org> - 2016-10-29 17:30 +0200
      Re: [PATCH 23/60] block: introduce flag QUEUE_FLAG_NO_MP Ming Lei <tom.leiming@gmail.com> - 2016-10-30 00:30 +0200

#1511585 — [PATCH 23/60] block: introduce flag QUEUE_FLAG_NO_MP

MD(especially raid1 and raid10) is a bit difficult to support
multipage bvec, so introduce this flag for not enabling multipage
bvec, then MD can still accept singlepage bvec only, and once
direct access to bvec table in MD and other fs/drivers are cleanuped,
the flag can be removed. BTRFS has the similar issue too.

Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
 include/linux/blkdev.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index c47c358ba052..e4dd25361bd6 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -505,6 +505,7 @@ struct request_queue {
 #define QUEUE_FLAG_FUA	       24	/* device supports FUA writes */
 #define QUEUE_FLAG_FLUSH_NQ    25	/* flush not queueuable */
 #define QUEUE_FLAG_DAX         26	/* device supports DAX */
+#define QUEUE_FLAG_NO_MP       27	/* multipage bvecs isn't ready */
 
 #define QUEUE_FLAG_DEFAULT	((1 << QUEUE_FLAG_IO_STAT) |		\
 				 (1 << QUEUE_FLAG_STACKABLE)	|	\
@@ -595,6 +596,7 @@ static inline void queue_flag_clear(unsigned int flag, struct request_queue *q)
 #define blk_queue_secure_erase(q) \
 	(test_bit(QUEUE_FLAG_SECERASE, &(q)->queue_flags))
 #define blk_queue_dax(q)	test_bit(QUEUE_FLAG_DAX, &(q)->queue_flags)
+#define blk_queue_no_mp(q)	test_bit(QUEUE_FLAG_NO_MP, &(q)->queue_flags)
 
 #define blk_noretry_request(rq) \
 	((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \
-- 
2.7.4

[toc] | [next] | [standalone]

#1511823

On Sat, Oct 29, 2016 at 04:08:22PM +0800, Ming Lei wrote:
> MD(especially raid1 and raid10) is a bit difficult to support
> multipage bvec, so introduce this flag for not enabling multipage
> bvec, then MD can still accept singlepage bvec only, and once
> direct access to bvec table in MD and other fs/drivers are cleanuped,
> the flag can be removed. BTRFS has the similar issue too.

There is really no good reason for that.  The RAID1 and 10 code really
just needs some love to use the bio cloning infrastructure, bio
iterators and generally recent bio apis.  btrfs just needs a tiny little
bit of help and I'll send patches soon.

Having two different code path is just asking for trouble in the long
run.

[toc] | [prev] | [next] | [standalone]

#1511926

On Sat, Oct 29, 2016 at 11:29 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Sat, Oct 29, 2016 at 04:08:22PM +0800, Ming Lei wrote:
>> MD(especially raid1 and raid10) is a bit difficult to support
>> multipage bvec, so introduce this flag for not enabling multipage
>> bvec, then MD can still accept singlepage bvec only, and once
>> direct access to bvec table in MD and other fs/drivers are cleanuped,
>> the flag can be removed. BTRFS has the similar issue too.
>
> There is really no good reason for that.  The RAID1 and 10 code really
> just needs some love to use the bio cloning infrastructure, bio
> iterators and generally recent bio apis.  btrfs just needs a tiny little
> bit of help and I'll send patches soon.

That is very nice of you to do this cleanup, cool!

I guess it still need a bit time, and hope that won't be the block
for the whole patchset, :-)

[linux-2.6-next]$git grep -n -E "bi_io_vec|bi_vcnt" ./fs/btrfs/ | wc -l
45

[linux-2.6-next]$git grep -n -E "bi_io_vec|bi_vcnt" ./drivers/md/ |
grep raid | wc -l
54

>
> Having two different code path is just asking for trouble in the long
> run.

Definitely, that flag is introduced just as a short-term solution.

Thanks,
Ming Lei

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web