From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: fam@euphon.net, Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org,
Christian Ehrhardt <christian.ehrhardt@canonical.com>,
f4bug@amsat.org, cota@braap.org,
Paolo Bonzini <pbonzini@redhat.com>,
aurelien@aurel32.net, Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v2 06/12] accel/tcg: better handle memory constrained systems
Date: Thu, 23 Jul 2020 10:31:08 +0100 [thread overview]
Message-ID: <20200723093108.GD2615312@redhat.com> (raw)
In-Reply-To: <87d04mtwku.fsf@linaro.org>
On Thu, Jul 23, 2020 at 10:22:25AM +0100, Alex Bennée wrote:
>
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> > On Wed, Jul 22, 2020 at 12:02:59PM -0700, Richard Henderson wrote:
> >> On 7/22/20 9:44 AM, Daniel P. Berrangé wrote:
> >> > OpenStack uses TCG in alot of their CI infrastructure for example
> >> > and runs multiple VMs. If there's 4 VMs, that's another 4 GB of
> >> > RAM usage just silently added on top of the explicit -m value.
> >> >
> >> > I wouldn't be surprised if this pushes CI into OOM, even without
> >> > containers or cgroups being involved, as they have plenty of other
> >> > services consuming RAM in the CI VMs.
> >>
> >> I would hope that CI would also supply a -tb_size to go along with that -m
> >> value. Because we really can't guess on their behalf.
> >
> > I've never even seen mention of -tb_size argument before myself, nor
> > seen anyone else using it and libvirt doesn't set it, so I think
> > this is not a valid assumption.
> >
> >
> >> > The commit 600e17b261555c56a048781b8dd5ba3985650013 talks about this
> >> > minimizing codegen cache flushes, but doesn't mention the real world
> >> > performance impact of eliminating those flushes ?
> >>
> >> Somewhere on the mailing list was this info. It was so dreadfully slow it was
> >> *really* noticable. Timeouts everywhere.
> >>
> >> > Presumably this makes the guest OS boot faster, but what's the before
> >> > and after time ? And what's the time like for values in between the
> >> > original 32mb and the new 1 GB ?
> >>
> >> But it wasn't "the original 32MB".
> >> It was the original "ram_size / 4", until that broke due to argument parsing
> >> ordering.
> >
> > Hmm, 600e17b261555c56a048781b8dd5ba3985650013 says it was 32 MB as the
> > default in its commit message, which seems to match the code doing
> >
> > #define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB)
>
> You need to look earlier in the sequence (see the tag pull-tcg-20200228):
>
> 47a2def4533a2807e48954abd50b32ecb1aaf29a
>
> so when the argument ordering broke the guest ram_size heuristic we
> started getting reports of performance regressions because we fell back
> to that size. Before then it was always based on guest ram size within
> the min/max bounds set by those defines.
Ah I see. That's a shame, as something based on guest RAM size feels like
a much safer bet for a default heuristic than basing it on host RAM size.
I'd probably say that the original commit which changed the argument
processing is flawed, and could/should be fixed.
The problem that commit was trying to solve was to do validation of the
value passed to -m. In fixing that it also moving the parsing. The key
problem here is that we need to do parsing and validating at different
points in the startup procedure. IOW, we need to split the logic, not
simply moving the CLI parsing to the place that makes validation work.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2020-07-23 9:32 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 6:28 [PATCH v2 00/12] candidate fixes for 5.1-rc1 (testing, semihosting, OOM tcg, x86 fpu) Alex Bennée
2020-07-22 6:28 ` [PATCH v2 01/12] shippable: add one more qemu to registry url Alex Bennée
2020-07-22 6:28 ` [PATCH v2 02/12] semihosting: defer connect_chardevs a little more to use serialx Alex Bennée
2020-07-22 6:28 ` [PATCH v2 03/12] semihosting: don't send the trailing '\0' Alex Bennée
2020-07-22 6:28 ` [PATCH v2 04/12] util: add qemu_get_host_physmem utility function Alex Bennée
2020-07-22 15:51 ` Richard Henderson
2020-07-22 6:28 ` [PATCH v2 05/12] util/oslib-win32: add qemu_get_host_physmem implementation Alex Bennée
2020-07-22 6:49 ` Philippe Mathieu-Daudé
2020-07-22 10:03 ` Stefan Weil
2020-07-22 10:13 ` Daniel P. Berrangé
2020-07-22 11:33 ` Alex Bennée
2020-07-22 11:38 ` Daniel P. Berrangé
2020-07-22 10:32 ` 罗勇刚(Yonggang Luo)
2020-07-22 10:50 ` Stefan Weil
2020-07-22 11:31 ` Alex Bennée
2020-07-22 11:41 ` Daniel P. Berrangé
2020-07-22 6:28 ` [PATCH v2 06/12] accel/tcg: better handle memory constrained systems Alex Bennée
2020-07-22 15:57 ` Richard Henderson
2020-07-22 16:29 ` Alex Bennée
2020-07-22 16:44 ` Daniel P. Berrangé
2020-07-22 19:02 ` Richard Henderson
2020-07-23 9:00 ` Daniel P. Berrangé
2020-07-23 9:22 ` Alex Bennée
2020-07-23 9:31 ` Daniel P. Berrangé [this message]
2020-07-23 10:06 ` Alex Bennée
2020-07-22 6:28 ` [PATCH v2 07/12] target/i386: floatx80: avoid compound literals in static initializers Alex Bennée
2020-07-22 6:45 ` Philippe Mathieu-Daudé
2020-07-22 6:28 ` [PATCH v2 08/12] linux-user: don't use MAP_FIXED in pgd_find_hole_fallback Alex Bennée
2020-07-22 16:00 ` Richard Henderson
2020-07-22 6:28 ` [PATCH v2 09/12] tests/docker: fix update command due to python3 str/bytes distinction Alex Bennée
2020-07-22 6:29 ` [PATCH v2 10/12] tests/docker: fix binfmt_misc image building Alex Bennée
2020-07-22 6:35 ` Philippe Mathieu-Daudé
2020-07-22 6:29 ` [PATCH v2 11/12] tests/docker: add support for DEB_KEYRING Alex Bennée
2020-07-22 14:27 ` Philippe Mathieu-Daudé
2020-07-22 16:03 ` Richard Henderson
2020-07-22 6:29 ` [PATCH v2 12/12] linux-user: fix clock_nanosleep() Alex Bennée
2020-07-22 6:49 ` Laurent Vivier
2020-07-22 8:33 ` Laurent Vivier
2020-07-22 8:55 ` Alex Bennée
2020-07-22 12:03 ` Laurent Vivier
2020-07-22 7:05 ` Philippe Mathieu-Daudé
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=20200723093108.GD2615312@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=aurelien@aurel32.net \
--cc=christian.ehrhardt@canonical.com \
--cc=cota@braap.org \
--cc=f4bug@amsat.org \
--cc=fam@euphon.net \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=rth@twiddle.net \
/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).