Messages in this thread | | | Date | Tue, 5 May 2015 09:59:58 -0400 | From | Tejun Heo <> | Subject | Re: [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
| |