From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH v2] kvmtool: Add parameter to specifiy number of threads in thread_pool Date: Tue, 30 Jun 2015 15:03:51 +0100 Message-ID: <20150630140351.GM27725@arm.com> References: <20150629074544.GA15313@alberich> <20150629094502.GA17474@arm.com> <20150629114333.GB3379@alberich> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kvm@vger.kernel.org" To: Andreas Herrmann Return-path: Received: from foss.arm.com ([217.140.101.70]:41798 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753021AbbF3OD4 (ORCPT ); Tue, 30 Jun 2015 10:03:56 -0400 Content-Disposition: inline In-Reply-To: <20150629114333.GB3379@alberich> Sender: kvm-owner@vger.kernel.org List-ID: Hi Andreas, On Mon, Jun 29, 2015 at 12:43:33PM +0100, Andreas Herrmann wrote: > With current code the number of threads added to the thread_pool > equals number of online CPUs. So on cn78xx we usually have 48 threads > per guest just for the thread_pool. IMHO this is overkill for guests > that just have a few vCPUs and/or if a guest is pinned to a subset of > host CPUs. E.g. > > # numactl -C 4,5,7,8 ./lkvm run -c 2 -m 256 -k paravirt -d rootfs.ext3 ... > # ps -La | grep threadpool-work | wc -l > 48 > > Don't change default behaviour (for sake of compatibility) but > introduce a new parameter ("-t" or "--threads") that allows to specify > number of threads to be created for the thread_pool: > > # numactl -C 4,5,7,8 ./lkvm run -c 2 -m 256 --threads 4 -k paravirt -d ... > # ps -La | grep threadpool-work | wc -l > 4 > > Signed-off-by: Andreas Herrmann > --- > builtin-run.c | 6 ++++++ > include/kvm/kvm-config.h | 1 + > util/threadpool.c | 2 +- > 3 files changed, 8 insertions(+), 1 deletion(-) > > New in v2: paramter must be in range [1, number of online cpus] > otherwise the default (number of online cpus) will be used. I thought some more about this and started to wonder whether we can make the threadpool self-balancing. Given the fairly restricted nature of kvmtool's threading model, could we not start with a small fixed number of threads (but no more than the number of physical CPUs) and then create new threads on demand when we detect that there is backlog in the job queue and there are spare CPUs? I don't think it should be too hard, especially if we ignore the problem of destroying idle threads and it removes the need for a magic tunable on the cmdline. Will