From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH v1 5/9] block: loop: convert to blk-mq Date: Fri, 15 Aug 2014 09:31:11 -0700 Message-ID: <20140815163111.GA16652@infradead.org> References: <1408031441-31156-1-git-send-email-ming.lei@canonical.com> <1408031441-31156-6-git-send-email-ming.lei@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jens Axboe , linux-kernel@vger.kernel.org, Andrew Morton , Dave Kleikamp , Zach Brown , Benjamin LaHaise , Christoph Hellwig , Kent Overstreet , linux-aio@kvack.org, linux-fsdevel@vger.kernel.org, Dave Chinner To: Ming Lei Return-path: Content-Disposition: inline In-Reply-To: <1408031441-31156-6-git-send-email-ming.lei@canonical.com> Sender: owner-linux-aio@kvack.org List-Id: linux-fsdevel.vger.kernel.org > + > +static int loop_init_hctx(struct blk_mq_hw_ctx *hctx, void *data, > + unsigned int index) > +{ > + struct loop_device *lo = data; > + > + hctx->driver_data = lo; I don't think there is much of a point to store this in the hctx instead of relying on the queue. > +static void loop_softirq_done_fn(struct request *rq) > +{ > + blk_mq_end_io(rq, rq->errors); > +} no need for a noop softirq done function. > +static void loop_queue_work(struct work_struct *work) Offloading work straight to a workqueue dosn't make much sense in the blk-mq model as we'll usually be called from one. If you need to avoid the cases where we are called directly a flag for the blk-mq code to always schedule a workqueue sounds like a much better plan. -- To unsubscribe, send a message with 'unsubscribe linux-aio' in the body to majordomo@kvack.org. For more info on Linux AIO, see: http://www.kvack.org/aio/ Don't email: aart@kvack.org