From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Suraj Jitindar Singh <sjitindarsingh@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
David Matlack <dmatlack@google.com>
Cc: linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
mpe@ellerman.id.au, paulus@samba.org, benh@kernel.crashing.org,
"kvm list" <kvm@vger.kernel.org>,
agraf@suse.com, "Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH V2 4/5] kvm/stats: Add provisioning for 64-bit vcpu statistics
Date: Mon, 18 Jul 2016 07:17:58 +0000 [thread overview]
Message-ID: <578C82A6.6090201@de.ibm.com> (raw)
In-Reply-To: <57889634.9030302@gmail.com>
On 07/15/2016 09:52 AM, Suraj Jitindar Singh wrote:
>
>
> On 14/07/16 19:42, Paolo Bonzini wrote:
>>
>> On 13/07/2016 20:00, Christian Borntraeger wrote:
>>>>>>> I thought u64 still existed on 32-bit architectures. unsigned long
>>>>>>> would be fine but with the caveat that certain stats would overflow on
>>>>>>> 32-bit architectures.
>>>>> Yes, but not all 32-bit architectures can do atomic read-modify-write
>>>>> (e.g. add) operations on 64-bit values.
>>> So what about only doing it for the VCPU events? Those should be only
>>> modified by one CPU. We would have some odd values on 32bit overflow, but
>>> this will be certainly better than just start with 0
>> If that's good enough for PPC, that's fine.
>>
>> Paolo
>
> I'm don't feel great about having vcpu_stats as u64 and vm_stats still as u32
> it's just a bit inconsistent.
>
> That being said, it's only the vcpu_stats which I require to be u64 at this
> stage so it's possible to just upgrade those.
Yes, its not nice, but we probably want to avoid the overhead of atomics.
What about using u64 for vcpu_stats and unsigned long for vm_stats. This will be
correct for anyone and on 64bit systems we get 64 bits for everything?
WARNING: multiple messages have this Message-ID (diff)
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Suraj Jitindar Singh <sjitindarsingh@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
David Matlack <dmatlack@google.com>
Cc: linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
mpe@ellerman.id.au, paulus@samba.org, benh@kernel.crashing.org,
"kvm list" <kvm@vger.kernel.org>,
agraf@suse.com, "Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH V2 4/5] kvm/stats: Add provisioning for 64-bit vcpu statistics
Date: Mon, 18 Jul 2016 09:17:58 +0200 [thread overview]
Message-ID: <578C82A6.6090201@de.ibm.com> (raw)
In-Reply-To: <57889634.9030302@gmail.com>
On 07/15/2016 09:52 AM, Suraj Jitindar Singh wrote:
>
>
> On 14/07/16 19:42, Paolo Bonzini wrote:
>>
>> On 13/07/2016 20:00, Christian Borntraeger wrote:
>>>>>>> I thought u64 still existed on 32-bit architectures. unsigned long
>>>>>>> would be fine but with the caveat that certain stats would overflow on
>>>>>>> 32-bit architectures.
>>>>> Yes, but not all 32-bit architectures can do atomic read-modify-write
>>>>> (e.g. add) operations on 64-bit values.
>>> So what about only doing it for the VCPU events? Those should be only
>>> modified by one CPU. We would have some odd values on 32bit overflow, but
>>> this will be certainly better than just start with 0
>> If that's good enough for PPC, that's fine.
>>
>> Paolo
>
> I'm don't feel great about having vcpu_stats as u64 and vm_stats still as u32
> it's just a bit inconsistent.
>
> That being said, it's only the vcpu_stats which I require to be u64 at this
> stage so it's possible to just upgrade those.
Yes, its not nice, but we probably want to avoid the overhead of atomics.
What about using u64 for vcpu_stats and unsigned long for vm_stats. This will be
correct for anyone and on 64bit systems we get 64 bits for everything?
next prev parent reply other threads:[~2016-07-18 7:17 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-11 7:08 [PATCH V2 1/5] kvm/ppc/book3s: Move struct kvmppc_vcore from kvm_host.h to kvm_book3s.h Suraj Jitindar Singh
2016-07-11 7:08 ` Suraj Jitindar Singh
2016-07-11 7:08 ` [PATCH V2 2/5] kvm/ppc/book3s_hv: Change vcore element runnable_threads from linked-list to array Suraj Jitindar Singh
2016-07-11 7:08 ` Suraj Jitindar Singh
2016-07-11 7:08 ` [PATCH V2 3/5] kvm/ppc/book3s_hv: Implement halt polling in the kvm_hv kernel module Suraj Jitindar Singh
2016-07-11 7:08 ` Suraj Jitindar Singh
2016-07-11 16:57 ` David Matlack
2016-07-11 16:57 ` David Matlack
2016-07-11 17:07 ` Paolo Bonzini
2016-07-11 17:07 ` Paolo Bonzini
2016-07-11 17:26 ` David Matlack
2016-07-11 17:26 ` David Matlack
2016-07-12 6:33 ` Suraj Jitindar Singh
2016-07-12 6:33 ` Suraj Jitindar Singh
2016-07-11 7:08 ` [PATCH V2 4/5] kvm/stats: Add provisioning for 64-bit vcpu statistics Suraj Jitindar Singh
2016-07-11 7:08 ` Suraj Jitindar Singh
2016-07-11 16:51 ` David Matlack
2016-07-11 16:51 ` David Matlack
2016-07-11 17:05 ` Paolo Bonzini
2016-07-11 17:05 ` Paolo Bonzini
2016-07-11 17:30 ` David Matlack
2016-07-11 17:30 ` David Matlack
2016-07-11 19:31 ` Paolo Bonzini
2016-07-11 19:31 ` Paolo Bonzini
2016-07-11 19:45 ` David Matlack
2016-07-11 19:45 ` David Matlack
2016-07-12 6:24 ` Suraj Jitindar Singh
2016-07-12 6:24 ` Suraj Jitindar Singh
2016-07-13 18:00 ` Christian Borntraeger
2016-07-13 18:00 ` Christian Borntraeger
2016-07-13 18:00 ` Christian Borntraeger
2016-07-14 9:42 ` Paolo Bonzini
2016-07-14 9:42 ` Paolo Bonzini
2016-07-15 7:52 ` Suraj Jitindar Singh
2016-07-15 7:52 ` Suraj Jitindar Singh
2016-07-18 7:17 ` Christian Borntraeger [this message]
2016-07-18 7:17 ` Christian Borntraeger
2016-07-18 8:24 ` Paolo Bonzini
2016-07-18 8:24 ` Paolo Bonzini
2016-07-19 1:31 ` Suraj Jitindar Singh
2016-07-19 1:31 ` Suraj Jitindar Singh
2016-07-11 7:08 ` [PATCH V2 5/5] powerpc/kvm/stats: Implement existing and add new halt polling vcpu stats Suraj Jitindar Singh
2016-07-11 7:08 ` Suraj Jitindar Singh
2016-07-11 16:49 ` David Matlack
2016-07-11 16:49 ` David Matlack
2016-07-12 6:17 ` Suraj Jitindar Singh
2016-07-12 6:17 ` Suraj Jitindar Singh
2016-07-13 6:07 ` Suraj Jitindar Singh
2016-07-13 6:07 ` Suraj Jitindar Singh
2016-07-13 17:20 ` David Matlack
2016-07-13 17:20 ` David Matlack
2016-07-15 7:53 ` Suraj Jitindar Singh
2016-07-15 7:53 ` Suraj Jitindar Singh
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=578C82A6.6090201@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=agraf@suse.com \
--cc=benh@kernel.crashing.org \
--cc=dmatlack@google.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=sjitindarsingh@gmail.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.