Messages in this thread | | | Date | Fri, 1 May 2015 10:22:21 -0400 | From | Tejun Heo <> | Subject | Re: [PATCH v6] block: loop: avoiding too many pending per work I/O |
| |
On Fri, May 01, 2015 at 09:36:47PM +0800, Ming Lei wrote: > On Fri, May 1, 2015 at 6:17 PM, Christoph Hellwig <hch@infradead.org> wrote: > > On Fri, May 01, 2015 at 11:28:01AM +0800, Ming Lei wrote: > >> If there are too many pending per work I/O, too many > >> high priority work thread can be generated so that > >> system performance can be effected.
Hmmm... why is it even marked HIGHPRI? The commit doesn't seem to explain why. Also, I wonder whether this would be better served by unbound workqueues. These tasks are mostly like to walk all the way through the filesystem and block layer. That can be quite a bit of processing for concurrency managed per-cpu workqueues and may effectively block out other work items which actually need to be HIGHPRI.
> >> This patch limits the max pending per work I/O as 16, > >> and will fackback to single queue mode when the max > >> number is reached. > > > > Why would you do this fall back? Shouldn't we just communicate > > a concurrency limit to the workqueue code? > > It can't work with workqueue's concurrency limit because the > queue is shared by all loop block devices, and the limit is on the > whole queue.
Maybe just cap max_active to NR_OF_LOOP_DEVS * 16 or sth? But idk, how many concurrent workers are we talking about and why are we capping per-queue concurrency from worker pool side instead of command tag side?
Thanks.
-- tejun
| |