qemu-trivial.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: Thomas Huth <thuth@redhat.com>,
	qemu-devel@nongnu.org, qemu-trivial@nongnu.org,
	Eduardo Habkost <eduardo@habkost.net>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Yanan Wang <wangyanan55@huawei.com>,
	Zhao Liu <zhao1.liu@intel.com>,
	Markus Armbruster <armbru@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, John Snow <jsnow@redhat.com>
Subject: Re: [RFC PATCH for-10.0] include/hw/boards: Optimize the booleans in MachineClass
Date: Mon, 25 Nov 2024 12:14:20 +0000	[thread overview]
Message-ID: <Z0RqHDJa-x0B_FPK@redhat.com> (raw)
In-Reply-To: <963aad3c-69aa-498b-9fba-2038ab4a3455@linaro.org>

On Mon, Nov 25, 2024 at 12:47:33PM +0100, Philippe Mathieu-Daudé wrote:
> On 25/11/24 12:03, Daniel P. Berrangé wrote:
> > 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.
> 
> While I agree with you on this, and the patch would take less
> than 1 minute, all of these fields are legacy options. Maybe
> a good opportunity to tackle this technical debt.
> 
> I.e. as of 2024 having to set no_parallel/no_floppy/no_cdrom
> to true to every new machines seems counter intuitive.

We don't set them for all machines though, they are all set
selectively, and this is machine ABI controlled. So we could
only remove this flags, once all versioned machines that have
them active, are deleted.

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 12:14 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é
2024-11-25 11:47   ` Philippe Mathieu-Daudé
2024-11-25 12:14     ` Daniel P. Berrangé [this message]

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=Z0RqHDJa-x0B_FPK@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=jsnow@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=pbonzini@redhat.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 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).