qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] hostmem: default the amount of prealloc-threads to smp-cpus


From: Igor Mammedov
Subject: Re: [PATCH] hostmem: default the amount of prealloc-threads to smp-cpus
Date: Thu, 19 May 2022 15:50:17 +0200

On Wed, 18 May 2022 16:06:47 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 5/18/22 15:31, Daniel P. Berrangé wrote:
> > When picking defaults there is never a perfect answer, it
> > is more a matter of the least-worst option.
> > 
> > It is pretty clear that nthreads=1 is terrible for any
> > large VMs. Defaulting it to nvcpus made conceptual sense
> > as the user has implicit said that they expect the VM to
> > be able to consume nvcpus worth of CPU time on the host,
> > so we might as well consume that allotted resource.

that assumes that allocation threads a permitted to actually
use all resources and not limited to 1 pcpu only and then it
also assumes 'more vcpus' => 'large RAM'.

> I agree.  Yes, one could argue that the regression was on the libvirt 
> side, but it's easier to fix it in QEMU.

libvirt already provides means to set threads number,
what needs fixing is setting up reasonable value in config
which depends on how VM is configured and constrains mgmt/host
put on it.

> If we later add the ability to create a memory backend before machine 
> creation (for example with a QMP-only binary), then it's of course okay 
> for those backends to use only one thread and require a manual choice 
> for the # or preallocation threads.

What I'm vehemently against is putting back direct machine
references into backend code. I'm fine with 'prealloc-threads'
property set from machine code (whether it's compat property or
some sugar_prop() crutch in vl.c to appease CLI users).

> 
> Paolo
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]