From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: David Edmondson <david.edmondson@oracle.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
qemu-block@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Max Reitz <mreitz@redhat.com>,
Shannon Zhao <shannon.zhaosl@gmail.com>,
qemu-arm@nongnu.org, Igor Mammedov <imammedo@redhat.com>,
John Snow <jsnow@redhat.com>
Subject: Re: [RFC PATCH 0/5] ARM: reduce the memory consumed when mapping UEFI flash images
Date: Mon, 16 Nov 2020 12:39:46 +0100 [thread overview]
Message-ID: <3da830b6-8200-6df9-9ba3-1f51bf887c4e@redhat.com> (raw)
In-Reply-To: <20201116104216.439650-1-david.edmondson@oracle.com>
Hi David,
On 11/16/20 11:42 AM, David Edmondson wrote:
> Currently ARM UEFI images are typically built as 2MB/768kB flash
> images for code and variables respectively. These images are both then
> padded out to 64MB before being loaded by QEMU.
>
> Because the images are 64MB each, QEMU allocates 128MB of memory to
> read them, and then proceeds to read all 128MB from disk (dirtying the
> memory). Of this 128MB less than 3MB is useful - the rest is zero
> padding.
2 years ago I commented the same problem, and suggested to access the
underlying storage by "block", as this is a "block storage".
Back then the response was "do not try to fix something that works".
This is why we choose the big hammer "do not accept image size not
matching device size" way.
While your series seems to help, it only postpone the same
implementation problem. If what you want is use the least memory
required, I still believe accessing the device by block is the
best approach.
Regards,
Phil.
>
> On a machine with 100 VMs this wastes over 12GB of memory.
>
> This set of patches aims to reclaim the wasted memory by allowing QEMU
> to respect the size of the flash images and allocate only the
> necessary memory. This will, of course, require that the flash build
> process be modified to avoid padding the images to 64MB.
>
> Because existing machine types expect the full 128MB reserved for
> flash to be occupied, do so for machine types older than virt-5.2. The
> changes are beneficial even in this case, because while the full 128MB
> of memory is allocated, only that required to actually load the flash
> images from disk is touched.
>
> David Edmondson (5):
> hw/block: blk_check_size_and_read_all should report backend name
> hw/block: Flash images can be smaller than the device
> hw/arm: Convert assertions about flash image size to error_report
> hw/arm: Flash image mapping follows image size
> hw/arm: Only minimise flash size on older machines
>
> hw/arm/trace-events | 2 +
> hw/arm/virt-acpi-build.c | 30 ++++++++------
> hw/arm/virt.c | 86 +++++++++++++++++++++++++++++-----------
> hw/block/block.c | 26 ++++++------
> include/hw/arm/virt.h | 2 +
> 5 files changed, 97 insertions(+), 49 deletions(-)
>
next prev parent reply other threads:[~2020-11-16 11:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-16 10:42 [RFC PATCH 0/5] ARM: reduce the memory consumed when mapping UEFI flash images David Edmondson
2020-11-16 10:42 ` [RFC PATCH 1/5] hw/block: blk_check_size_and_read_all should report backend name David Edmondson
2020-11-16 11:23 ` Philippe Mathieu-Daudé
2020-11-16 13:29 ` David Edmondson
2020-11-19 11:56 ` Alex Bennée
2020-11-16 10:42 ` [RFC PATCH 2/5] hw/block: Flash images can be smaller than the device David Edmondson
2020-11-16 10:42 ` [RFC PATCH 3/5] hw/arm: Convert assertions about flash image size to error_report David Edmondson
2020-11-19 11:39 ` Alex Bennée
2020-11-16 10:42 ` [RFC PATCH 4/5] hw/arm: Flash image mapping follows image size David Edmondson
2020-11-16 10:42 ` [RFC PATCH 5/5] hw/arm: Only minimise flash size on older machines David Edmondson
2020-11-16 11:39 ` Philippe Mathieu-Daudé [this message]
2020-11-16 13:43 ` [RFC PATCH 0/5] ARM: reduce the memory consumed when mapping UEFI flash images David Edmondson
2020-11-16 13:48 ` Markus Armbruster
2020-11-19 6:09 ` Philippe Mathieu-Daudé
2020-11-19 11:45 ` Alex Bennée
2020-11-19 11:57 ` Philippe Mathieu-Daudé
2020-12-07 12:07 ` David Edmondson
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=3da830b6-8200-6df9-9ba3-1f51bf887c4e@redhat.com \
--to=philmd@redhat.com \
--cc=armbru@redhat.com \
--cc=david.edmondson@oracle.com \
--cc=imammedo@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shannon.zhaosl@gmail.com \
/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).