From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753945AbbEAOW1 (ORCPT ); Fri, 1 May 2015 10:22:27 -0400 Received: from mail-qc0-f177.google.com ([209.85.216.177]:35671 "EHLO mail-qc0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753650AbbEAOWZ (ORCPT ); Fri, 1 May 2015 10:22:25 -0400 Date: Fri, 1 May 2015 10:22:21 -0400 From: Tejun Heo To: Ming Lei Cc: Christoph Hellwig , Jens Axboe , Linux Kernel Mailing List , "Justin M. Forbes" , Jeff Moyer , "v4.0" Subject: Re: [PATCH v6] block: loop: avoiding too many pending per work I/O Message-ID: <20150501142221.GC1949@htj.duckdns.org> References: <1430450881-10881-1-git-send-email-ming.lei@canonical.com> <20150501101737.GA18577@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 01, 2015 at 09:36:47PM +0800, Ming Lei wrote: > On Fri, May 1, 2015 at 6:17 PM, Christoph Hellwig 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