From: Laurent Vivier <Laurent.Vivier@bull.net>
To: Glauber de Oliveira Costa <glommer@gmail.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
John Stoffel <john@stoffel.org>,
kvm-devel <kvm-devel@lists.sourceforge.net>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>,
virtualization <virtualization@lists.linux-foundation.org>
Subject: Re: Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting
Date: Tue, 21 Aug 2007 09:45:53 +0200 [thread overview]
Message-ID: <46CA9831.4080309@bull.net> (raw)
In-Reply-To: <5d6222a80708201334q27fc6cbcr7ce6a9d7147437a2@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]
Glauber de Oliveira Costa wrote:
>> by doing this at kernel level, we can:
>> - measure exactly the guest time,
>> - move this part of system time to user time (as you think it should be
>> user time),
>> - have consistency between system, user and guest time,
>> - report values in /proc/state and /proc/<pid>/state, at system wide level
>>
>> I'm not sure we can measure the guest time at the qemu user level.
>>
>> Perhaps Rusty can say what he thinks about this ?
>>
> Even if we cannot _now_, isn't that an easier, and safer change? (and
> I don't think we lose anything by design).
Could you explain ? How should I do this ?
I'm _sure_ it is not easier to do that at qemu level.
I don't like to patch kernel (it is the last thing I do to solve a problem: I
know there is always at least one guy to not agree the patch :-P ) but in this
case I think this is the best way to do that.
I think the virtualization notion should be introduced at the kernel level, at
least in the kernel statistics: it is generic, it can be used by other
virtualization tools. As I said, until know CPUs have got only two states
reflected in statistics by "user time" and "system time". Since recently, they
have introduced a third state, the virtual CPU, that, in my opinion, should be
also reflected in the CPU statistics as the "guest time".
>
> Although I don't know KVM to a that deep level, I think it should be
> possible to keep the virtual cpus in different process (or threads),
> and take the accounting time from there. Perfectly possible to know
> the time we spent running (user time), and the time the hypervisor
> spent doing things on our behalf (system time).
But we have always user time accounted as system time. CPU stats are wrong if we
do not modify the kernel. Can you live with wrong statistics ? (yes, I think,
you can, but perhaps someone else not)
Laurent
--
------------- Laurent.Vivier@bull.net --------------
"Software is hard" - Donald Knuth
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-08-21 7:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-20 17:54 Réf. : Re: [PATCH 0/4] Virtual Machine Time Accounting laurent.vivier
2007-08-20 20:34 ` Glauber de Oliveira Costa
2007-08-21 7:45 ` Laurent Vivier [this message]
2007-08-21 17:46 ` Glauber de Oliveira Costa
2007-08-21 8:06 ` [kvm-devel] " Christian Borntraeger
2007-08-21 17:47 ` Glauber de Oliveira Costa
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=46CA9831.4080309@bull.net \
--to=laurent.vivier@bull.net \
--cc=glommer@gmail.com \
--cc=jeremy@goop.org \
--cc=john@stoffel.org \
--cc=kvm-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=virtualization@lists.linux-foundation.org \
/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