lkml.org 
[lkml]   [2015]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] block: loop: avoiding too many pending per work I/O
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?

Thanks.

--
tejun


\
 
 \ /
  Last update: 2015-05-05 16:41    [W:0.325 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site