All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-trivial@nongnu.org,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	"Zhao Liu" <zhao1.liu@intel.com>
Subject: Re: [RFC PATCH for-10.0] include/hw/boards: Optimize the booleans in MachineClass
Date: Mon, 25 Nov 2024 11:03:53 +0000	[thread overview]
Message-ID: <Z0RZmfjJmaHsfmWy@redhat.com> (raw)
In-Reply-To: <20241122084923.1542743-1-thuth@redhat.com>

On Fri, Nov 22, 2024 at 09:49:23AM +0100, Thomas Huth wrote:
> While looking at the QEMU binary with "pahole", I noticed that we
> could optimize the size of MachineClass a little bit: So far we
> are using a mixture of a bitfield and single "bool" members here
> for the boolean flags. Declaring all flags as part of the bitfield
> helps to shrink the size of the struct a little bit.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  It's just a micro-optimization (the size of the struct decreases by
>  eight bytes), so I'm not sure whether it's worth the effort...?

Given that this is a QOM class, rather than an instance, we'll
only ever save memory once. That's an unmeasurably small real
world improvement. We also have no ABI reasons to use bitfields
for this.

So if anything I'd suggest we take the opposite approach, and
eliminate that bitfields in favour of just using 'bool' for
everything, on the basis that a bitfield has no reason to
exist.

This could become useful if we aim to institute a general ban
on the use of bitfields in QEMU, as a way to avoid the struct
packing differences on Windows.

>  include/hw/boards.h | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 36fbb9b59d..c6946bd319 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -285,8 +285,16 @@ struct MachineClass {
>          no_cdrom:1,
>          no_sdcard:1,
>          pci_allow_0_address:1,
> -        legacy_fw_cfg_order:1;
> -    bool is_default;
> +        legacy_fw_cfg_order:1,
> +        is_default:1,
> +        auto_enable_numa_with_memhp:1,
> +        auto_enable_numa_with_memdev:1,
> +        ignore_boot_device_suffixes:1,
> +        smbus_no_migration_support:1,
> +        nvdimm_supported:1,
> +        numa_mem_supported:1,
> +        auto_enable_numa:1,
> +        cpu_cluster_has_numa_boundary:1;
>      const char *default_machine_opts;
>      const char *default_boot_order;
>      const char *default_display;
> @@ -304,14 +312,6 @@ struct MachineClass {
>      int numa_mem_align_shift;
>      const char * const *valid_cpu_types;
>      strList *allowed_dynamic_sysbus_devices;
> -    bool auto_enable_numa_with_memhp;
> -    bool auto_enable_numa_with_memdev;
> -    bool ignore_boot_device_suffixes;
> -    bool smbus_no_migration_support;
> -    bool nvdimm_supported;
> -    bool numa_mem_supported;
> -    bool auto_enable_numa;
> -    bool cpu_cluster_has_numa_boundary;
>      SMPCompatProps smp_props;
>      const char *default_ram_id;
>  
> -- 
> 2.47.0
> 
> 

With 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 :|



  reply	other threads:[~2024-11-25 11:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-22  8:49 [RFC PATCH for-10.0] include/hw/boards: Optimize the booleans in MachineClass Thomas Huth
2024-11-25 11:03 ` Daniel P. Berrangé [this message]
2024-11-25 11:47   ` Philippe Mathieu-Daudé
2024-11-25 12:14     ` Daniel P. Berrangé

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=Z0RZmfjJmaHsfmWy@redhat.com \
    --to=berrange@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wangyanan55@huawei.com \
    --cc=zhao1.liu@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.