From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
To: kvm-ppc@vger.kernel.org
Subject: Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction
Date: Tue, 15 Apr 2008 06:20:48 +0000 [thread overview]
Message-ID: <48044940.4070403@linux.vnet.ibm.com> (raw)
In-Reply-To: <200804141545.27659.hollisb@us.ibm.com>
Hollis Blanchard wrote:
> On Monday 14 April 2008 07:23:57 ehrhardt@linux.vnet.ibm.com wrote:
>> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
>>
>> This adds a relayfs based kernel interface that allows tracing of all
>> emulated guest instructions. It is based on Hollis tracing of tlb
>> activities. A suitable userspace program to read from that interface and a
>> post processing script that give users a readable output follow.
>> This feature is configurable in .config under the kvmppc virtualization
>> itself.
>
> I'm not sure how I feel about logging *every* faulting instruction, rather
> than aggregating statistics about them. Actually, I know how I feel, and it's
> uncomfortable. :)
>
> It's a userspace process that must be extracting this data from the relay
> buffers, and that only happens when it's scheduled. How many instruction
> exits could we get in a few timeslices? I think we could easily overflow the
> relay buffers, especially if the host is under load.
The patch series intentionally has two instruction statistics.
One for low overhead giving you just some counters, and additionally we can extend these counters as we want e.g. with sprn numbers.
The other is to enable knowingly a high overhead profiling, but it gives you a full trace which can be used e.g. to completely see "what exactly is the guest doing there" by looking at which instructions are emulated in which order.
So both have there right to exist, because there are use scenarios for both of them. By making them configurable it is developers choice what to use.
>> +struct instr_record {
>> + u32 time;
>> + u32 pc;
>> + u32 instr;
>> + u32 rsval;
>> + u32 raval;
>> + u32 rbval;
>> +};
>
> In addition to the instruction itself, I can see how the PC would be useful,
> and maybe also the time when we have multiple cores. (Well, or maybe it would
> be better to have one channel per core anyways.) But I think RS/RA/RB are way
> overkill here. What would a userspace tool do with this data anyways?
>
The decoding scripts shows you what values are used e.g. for a mtmsr you see what value was moved to the register.
But I agree that the value of r*val is much smaller than time,pc,instr.
Removing these three should speed it up to allow us tracing all instructions.
I will change the patch and resend it.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
kvm-ppc-devel mailing list
kvm-ppc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel
next prev parent reply other threads:[~2008-04-15 6:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-14 20:45 [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction Hollis Blanchard
2008-04-15 6:20 ` Christian Ehrhardt [this message]
2008-04-15 14:20 ` Hollis Blanchard
2008-04-15 21:01 ` Hollis Blanchard
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=48044940.4070403@linux.vnet.ibm.com \
--to=ehrhardt@linux.vnet.ibm.com \
--cc=kvm-ppc@vger.kernel.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 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.