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@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html