Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2994106AbbEEQIF (ORCPT ); Tue, 5 May 2015 12:08:05 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:34182 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2993236AbbEEOqN (ORCPT ); Tue, 5 May 2015 10:46:13 -0400 MIME-Version: 1.0 In-Reply-To: <20150505135958.GO1971@htj.duckdns.org> References: <1430826595-5888-1-git-send-email-ming.lei@canonical.com> <1430826595-5888-3-git-send-email-ming.lei@canonical.com> <20150505135958.GO1971@htj.duckdns.org> Date: Tue, 5 May 2015 22:46:10 +0800 Message-ID: Subject: Re: [PATCH 2/2] block: loop: avoiding too many pending per work I/O From: Ming Lei To: Tejun Heo Cc: Jens Axboe , Linux Kernel Mailing List , "Justin M. Forbes" , Jeff Moyer , Christoph Hellwig , "v4.0" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1676 Lines: 35 On Tue, May 5, 2015 at 9:59 PM, Tejun Heo wrote: > On Tue, May 05, 2015 at 07:49:55PM +0800, Ming Lei wrote: > ... >> diff --git a/drivers/block/loop.c b/drivers/block/loop.c >> index 3dc1598..1bee523 100644 >> --- a/drivers/block/loop.c >> +++ b/drivers/block/loop.c >> @@ -725,7 +725,7 @@ static int loop_set_fd(struct loop_device *lo, fmode_t mode, >> goto out_putf; >> error = -ENOMEM; >> lo->wq = alloc_workqueue("kloopd%d", >> - WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 0, >> + WQ_MEM_RECLAIM | WQ_HIGHPRI | WQ_UNBOUND, 16, > > It's a bit weird to hard code this to 16 as this effectively becomes a > hidden bottleneck for concurrency. For cases where 16 isn't a good > value, hunting down what's going on can be painful as it's not visible > anywhere. I still think the right knob to control concurrency is > nr_requests for the loop device. You said that for linear IOs, it's > better to have higher nr_requests than concurrency but can you > elaborate why? I mean, in case of sequential IO, the IO may hit page cache a bit easier, so handling the IO may be quite quick, then it is often more efficient to handle them in one same context(such as, handle one by one from IO queue) than from different contexts(scheduled from different worker threads). And that can be made by setting a bigger nr_requests(queue_depth). Thanks, Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/