From: Igor Mammedov <imammedo@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
"Dario Faggioli" <dfaggioli@suse.com>,
dzejrou@gmail.com, qemu-devel@nongnu.org, david@redhat.com
Subject: Re: [PATCH] hostmem: default the amount of prealloc-threads to smp-cpus
Date: Thu, 19 May 2022 15:50:17 +0200 [thread overview]
Message-ID: <20220519155017.71f9ec6d@redhat.com> (raw)
In-Reply-To: <9851633b-d9a3-bc71-afd1-d24fe8972177@redhat.com>
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
>
prev parent reply other threads:[~2022-05-19 13:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-17 12:38 [PATCH] hostmem: default the amount of prealloc-threads to smp-cpus dzejrou
2022-05-17 15:12 ` Igor Mammedov
2022-05-17 15:44 ` Jaroslav Jindrák
2022-05-17 16:33 ` Daniel P. Berrangé
2022-05-18 10:08 ` Igor Mammedov
2022-05-17 18:46 ` Paolo Bonzini
2022-05-18 10:17 ` Igor Mammedov
2022-05-18 13:02 ` Dario Faggioli
2022-05-18 13:31 ` Daniel P. Berrangé
2022-05-18 14:06 ` Paolo Bonzini
2022-05-19 13:50 ` Igor Mammedov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220519155017.71f9ec6d@redhat.com \
--to=imammedo@redhat.com \
--cc=berrange@redhat.com \
--cc=david@redhat.com \
--cc=dfaggioli@suse.com \
--cc=dzejrou@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).