Re: [PATCH v2 0/9] hw, ui, virtfs-proxy-helper: Reduce QEMU .data/.rodata/.bss footprint

[Eric Blake]

On 3/5/20 7:56 AM, Philippe Mathieu-Daudé wrote:
> On 3/5/20 2:42 PM, Daniel P. Berrangé wrote:
> > On Thu, Mar 05, 2020 at 01:45:16PM +0100, Philippe Mathieu-Daudé wrote:
> > > Since v1:
> > > - merged 2 series
> > > - reworked hw/usb/quirks
> > > - added R-b/A-b tags
> > >
> > > This series reduce the footprint of the QEMU binary:
> > > .bss: 106KiB (moved to .heap)
> >
> > Did this actually have an impact on the binary size, or just on the
> > size the elf-dissector reports ?  I'm not very familiar with ELF,
> > but Wikipedia's description of BSS makes me question it...
> >
> >    "Typically only the length of the bss section, but no data,
> >     is stored in the object file. The program loader allocates
> >     memory for the bss section when it loads the program. On
> >     some platforms, some or all of the bss section is initialized
> >     to zeroes. Unix-like systems and Windows initialize the bss
> >     section to zero"
> >
> > This suggests .bss has no on-disk overhead, only runtime overhead,
> > which is presumably going to be the same with heap allocations.
>
> IIUC when stored in the .bss, the buffer are always allocated in memory, 
> even if not used. By moving them to the .heap, we only allocate them 
> when using either the adlib audio device or curses.

Virtual memory is cheap on 64-bit platforms.  Just because the address 
range is reserved does not actually change the amount of memory in use 
by the machine, if the application does not touch those virtual 
addresses.  But you do have a potential point on a 32-bit platform, 
where a heap allocation only when needed may avoid address space 
exhaustion for other cases.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org