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