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

[Eric Blake <eblake@redhat.com>]

On 3/5/20 7:42 AM, 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.

Or even LESS overhead.  Heap allocationhave unspecified contents 
requiring runtime effort (true, some implementations of malloc() handle 
large allocations specially as anonymous mmap initially backed by 
/dev/zero, so that those allocations start life 0-allocated, but you 
can't rely on that optimization), while .bss is required by the C 
language to be 0 initialized (and you CAN rely on the OS implementing 
that as efficiently as possible, generally by starting with COW mapping 
initially backed by the zero page).

In fact, on nbdkit, we hit an interesting case where using .bss instead 
of .rodata is actually beneficial:
https://www.redhat.com/archives/libguestfs/2019-July/msg00074.html
Marking a large array that will always consist only of zero bytes as 
const actually pessimized the image size and load time, because the 
addition of const moved the array from .bss into .rodata.

> 
>> .data: 1MiB
>> .rodata: 4.34MiB
> 
> These looks useful though in terms of disk footprint.

Yes. Smaller data structures allow for smaller binaries and faster loading.

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