LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Kiyoshi Ueda <k-ueda@ct.jp.nec.com> To: jens.axboe@oracle.com, agk@redhat.com, James.Bottomley@HansenPartnership.com Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, dm-devel@redhat.com, j-nomura@ce.jp.nec.com, k-ueda@ct.jp.nec.com Subject: [PATCH 05/13] block: add a queue flag for request stacking support Date: Fri, 12 Sep 2008 10:43:35 -0400 (EDT) [thread overview] Message-ID: <20080912.104335.88699296.k-ueda@ct.jp.nec.com> (raw) In-Reply-To: <20080912.103814.74754581.k-ueda@ct.jp.nec.com> This patch adds a queue flag to indicate the block device can be used for request stacking. Request stacking drivers need to stack their devices on top of only devices of which q->request_fn is functional. Since bio stacking drivers (e.g. md, loop) basically initialize their queue using blk_alloc_queue() and don't set q->request_fn, the check of (q->request_fn == NULL) looks enough for that purpose. However, dm becomes both types of stacking driver (bio-based and request-based) with this patch-set. And dm always sets q->request_fn even if the dm device is bio-based of which q->request_fn is not functional actually. So we need something else to distinguish the type of the device. Adding a queue flag is a solution for that. The reason why dm always sets q->request_fn is to keep the compatibility of dm user-space tools. Currently, all dm user-space tools are using bio-based dm without specifying the type of the dm device they use. To use request-based dm without changing such tools, the kernel must decide the type of the dm device automatically. The automatic type decision can't be done at the device creation time and needs to be deferred until such tools load a mapping table, since the actual type is decided by dm target type included in the mapping table. So a dm device has to be initialized using blk_init_queue() so that we can load either type of table. Then, all queue stuffs are set (e.g. q->request_fn) and we have no element to distinguish that it is bio-based or request-based, even after a table is loaded and the type of the device is decided. By the way, some stuffs of the queue (e.g. request_list, elevator) are needless when the dm device is used as bio-based. But the memory size is not so large (about 20[KB] per queue on ia64), so I hope the memory loss can be acceptable for bio-based dm users. Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com> Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com> Cc: Jens Axboe <jens.axboe@oracle.com> --- block/blk-core.c | 3 ++- include/linux/blkdev.h | 3 +++ 2 files changed, 5 insertions(+), 1 deletion(-) Index: 2.6.27-rc6/block/blk-core.c =================================================================== --- 2.6.27-rc6.orig/block/blk-core.c +++ 2.6.27-rc6/block/blk-core.c @@ -569,7 +569,8 @@ blk_init_queue_node(request_fn_proc *rfn q->request_fn = rfn; q->prep_rq_fn = NULL; q->unplug_fn = generic_unplug_device; - q->queue_flags = (1 << QUEUE_FLAG_CLUSTER); + q->queue_flags = (1 << QUEUE_FLAG_CLUSTER | + 1 << QUEUE_FLAG_STACKABLE); q->queue_lock = lock; blk_queue_segment_boundary(q, 0xffffffff); Index: 2.6.27-rc6/include/linux/blkdev.h =================================================================== --- 2.6.27-rc6.orig/include/linux/blkdev.h +++ 2.6.27-rc6/include/linux/blkdev.h @@ -421,6 +421,7 @@ struct request_queue #define QUEUE_FLAG_ELVSWITCH 8 /* don't use elevator, just do FIFO */ #define QUEUE_FLAG_BIDI 9 /* queue supports bidi requests */ #define QUEUE_FLAG_NOMERGES 10 /* disable merge attempts */ +#define QUEUE_FLAG_STACKABLE 11 /* supports request stacking */ static inline int queue_is_locked(struct request_queue *q) { @@ -527,6 +528,8 @@ enum { #define blk_queue_stopped(q) test_bit(QUEUE_FLAG_STOPPED, &(q)->queue_flags) #define blk_queue_nomerges(q) test_bit(QUEUE_FLAG_NOMERGES, &(q)->queue_flags) #define blk_queue_flushing(q) ((q)->ordseq) +#define blk_queue_stackable(q) \ + test_bit(QUEUE_FLAG_STACKABLE, &(q)->queue_flags) #define blk_fs_request(rq) ((rq)->cmd_type == REQ_TYPE_FS) #define blk_pc_request(rq) ((rq)->cmd_type == REQ_TYPE_BLOCK_PC)
next prev parent reply other threads:[~2008-09-12 14:43 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-09-12 14:38 [PATCH 00/13] request-based dm-multipath Kiyoshi Ueda 2008-09-12 14:40 ` [PATCH 01/13] block: add request update interface Kiyoshi Ueda 2008-09-12 14:41 ` [PATCH 02/13] block: add request submission interface Kiyoshi Ueda 2008-09-14 13:10 ` Boaz Harrosh 2008-09-16 16:06 ` Kiyoshi Ueda 2008-09-16 17:02 ` Jens Axboe 2008-09-16 18:12 ` Kiyoshi Ueda 2008-09-12 14:42 ` [PATCH 03/13] mm: lld busy status exporting interface Kiyoshi Ueda 2008-09-12 14:43 ` [PATCH 04/13] scsi: exports busy status Kiyoshi Ueda 2008-09-12 14:43 ` Kiyoshi Ueda [this message] 2008-09-12 14:44 ` [PATCH 06/13] dm: remove unused DM_WQ_FLUSH_ALL Kiyoshi Ueda 2008-09-12 14:44 ` [PATCH 07/13] dm: tidy local_init Kiyoshi Ueda 2008-09-12 14:45 ` [PATCH 08/13] dm: add kmem_cache for request-based dm Kiyoshi Ueda 2008-09-12 14:45 ` [PATCH 09/13] dm: add target interfaces " Kiyoshi Ueda 2008-09-12 14:46 ` [PATCH 10/13] dm: add core functions " Kiyoshi Ueda 2008-10-24 7:44 ` [dm-devel] " Nikanth K 2008-10-28 16:00 ` Kiyoshi Ueda [not found] ` <490FB852.3FEE.00C5.1@novell.com> [not found] ` <49102C03020000C50002E257@victor.provo.novell.com> 2008-11-04 15:01 ` Kiyoshi Ueda 2008-09-12 14:46 ` [PATCH 11/13] dm: enable " Kiyoshi Ueda 2008-10-24 7:52 ` [dm-devel] " Nikanth K 2008-10-28 16:02 ` Kiyoshi Ueda 2008-09-12 14:46 ` [PATCH 12/13] dm: reject I/O violating new queue limits Kiyoshi Ueda 2008-09-12 14:47 ` [PATCH 13/13] dm-mpath: convert to request-based Kiyoshi Ueda 2008-10-24 7:55 ` [dm-devel] " Nikanth K 2008-10-28 16:03 ` Kiyoshi Ueda 2008-09-14 13:17 ` [PATCH 00/13] request-based dm-multipath Jens Axboe
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=20080912.104335.88699296.k-ueda@ct.jp.nec.com \ --to=k-ueda@ct.jp.nec.com \ --cc=James.Bottomley@HansenPartnership.com \ --cc=agk@redhat.com \ --cc=dm-devel@redhat.com \ --cc=j-nomura@ce.jp.nec.com \ --cc=jens.axboe@oracle.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@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: linkBe 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).