From: Paolo Bonzini <pbonzini@redhat.com>
To: Like Xu <like.xu@linux.intel.com>, Peter Zijlstra <peterz@infradead.org>
Cc: kvm@vger.kernel.org, rkrcmar@redhat.com,
sean.j.christopherson@intel.com, vkuznets@redhat.com,
Jim Mattson <jmattson@google.com>, Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
ak@linux.intel.com, wei.w.wang@intel.com, kan.liang@intel.com,
like.xu@intel.com, ehankland@google.com, arbel.moshe@oracle.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] KVM: x86/vPMU: Add lazy mechanism to release perf_event per vPMC
Date: Wed, 9 Oct 2019 09:15:03 +0200 [thread overview]
Message-ID: <bfd23868-064e-4bf5-4dfb-211d36c409c1@redhat.com> (raw)
In-Reply-To: <d492e08e-bf14-0a8b-bc8c-397f8893ddb5@linux.intel.com>
On 09/10/19 05:14, Like Xu wrote:
>>
>>
>>> I'm not sure is this your personal preference or is there a technical
>>> reason such as this usage is not incompatible with union syntax?
>>
>> Apparently it 'works', so there is no hard technical reason, but
>> consider that _Bool is specified as an integer type large enough to
>> store the values 0 and 1, then consider it as a base type for a
>> bitfield. That's just disguisting.
>
> It's reasonable. Thanks.
/me chimes in since this is KVM code after all...
For stuff like hardware registers, bitfields are probably a bad idea
anyway, so let's only consider the case of space optimization.
bool:2 would definitely cause an eyebrow raise, but I don't see why
bool:1 bitfields are a problem. An integer type large enough to store
the values 0 and 1 can be of any size bigger than one bit.
bool bitfields preserve the magic behavior where something like this:
foo->x = y;
(x is a bool bitfield) would be compiled as
foo->x = (y != 0);
which can be a plus or a minus depending on the point of view. :)
Either way, bool bitfields are useful if you are using bitfields for
space optimization, especially if you have existing code using bool and
it might rely on the idiom above.
However, in this patch bitfields are unnecessary and they result in
worse code from the compiler. There is plenty of padding in struct
kvm_pmu, with or without bitfields, so I'd go with "u8 event_count; bool
enable_cleanup;" (or better "need_cleanup").
Thanks,
Paolo
next prev parent reply other threads:[~2019-10-09 7:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-30 7:22 [PATCH 0/3] KVM: x86/vPMU: Efficiency optimization by reusing last created perf_event Like Xu
2019-09-30 7:22 ` [PATCH 1/3] perf/core: Provide a kernel-internal interface to recalibrate event period Like Xu
2019-10-01 2:27 ` kbuild test robot
2019-10-01 2:46 ` kbuild test robot
2019-10-07 12:01 ` Paolo Bonzini
2019-10-07 13:25 ` Liang, Kan
2019-10-07 15:05 ` Paolo Bonzini
2019-09-30 7:22 ` [PATCH 2/3] KVM: x86/vPMU: Reuse perf_event to avoid unnecessary pmc_reprogram_counter Like Xu
2019-10-01 8:22 ` Peter Zijlstra
2019-10-01 12:18 ` Like Xu
2019-09-30 7:22 ` [PATCH 3/3] KVM: x86/vPMU: Add lazy mechanism to release perf_event per vPMC Like Xu
2019-10-01 8:23 ` Peter Zijlstra
2019-10-01 12:33 ` Like Xu
2019-10-08 12:11 ` Peter Zijlstra
2019-10-09 3:14 ` Like Xu
2019-10-09 7:15 ` Paolo Bonzini [this message]
2019-10-09 8:07 ` Like Xu
2019-10-09 8:16 ` Peter Zijlstra
2019-10-09 9:21 ` Paolo Bonzini
2019-10-09 9:32 ` Peter Zijlstra
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=bfd23868-064e-4bf5-4dfb-211d36c409c1@redhat.com \
--to=pbonzini@redhat.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=arbel.moshe@oracle.com \
--cc=ehankland@google.com \
--cc=jmattson@google.com \
--cc=kan.liang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=like.xu@intel.com \
--cc=like.xu@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rkrcmar@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=vkuznets@redhat.com \
--cc=wei.w.wang@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
all inboxes | Powered by JetHome®