* Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction
@ 2008-04-14 20:45 Hollis Blanchard
2008-04-15 6:20 ` Christian Ehrhardt
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Hollis Blanchard @ 2008-04-14 20:45 UTC (permalink / raw
To: kvm-ppc
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.
> +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?
--
Hollis Blanchard
IBM Linux Technology Center
-------------------------------------------------------------------------
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction
2008-04-14 20:45 [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction Hollis Blanchard
@ 2008-04-15 6:20 ` Christian Ehrhardt
2008-04-15 14:20 ` Hollis Blanchard
2008-04-15 21:01 ` Hollis Blanchard
2 siblings, 0 replies; 4+ messages in thread
From: Christian Ehrhardt @ 2008-04-15 6:20 UTC (permalink / raw
To: kvm-ppc
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction
2008-04-14 20:45 [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction Hollis Blanchard
2008-04-15 6:20 ` Christian Ehrhardt
@ 2008-04-15 14:20 ` Hollis Blanchard
2008-04-15 21:01 ` Hollis Blanchard
2 siblings, 0 replies; 4+ messages in thread
From: Hollis Blanchard @ 2008-04-15 14:20 UTC (permalink / raw
To: kvm-ppc
On Tuesday 15 April 2008 01:20:48 Christian Ehrhardt wrote:
> > 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.
I guess it can be useful to see what's happening when a guest is
getting "stuck".
However, there are other interesting events to account for in this case as
well, such as the TLB tracing I posted earlier. I think it makes sense to
include all of those events in the same relay channel, rather than having one
channel for instructions, one for TLB, etc.
> >> +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.
Does that really speed it up? I wouldn't expect a measurable difference.
--
Hollis Blanchard
IBM Linux Technology Center
-------------------------------------------------------------------------
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction
2008-04-14 20:45 [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction Hollis Blanchard
2008-04-15 6:20 ` Christian Ehrhardt
2008-04-15 14:20 ` Hollis Blanchard
@ 2008-04-15 21:01 ` Hollis Blanchard
2 siblings, 0 replies; 4+ messages in thread
From: Hollis Blanchard @ 2008-04-15 21:01 UTC (permalink / raw
To: kvm-ppc
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.
>
> Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
By the way, check out the new kvm_trace stuff checked in to kvm.git last week.
Looks like we'll probably want to use that.
--
Hollis Blanchard
IBM Linux Technology Center
-------------------------------------------------------------------------
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-04-15 21:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-14 20:45 [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction Hollis Blanchard
2008-04-15 6:20 ` Christian Ehrhardt
2008-04-15 14:20 ` Hollis Blanchard
2008-04-15 21:01 ` Hollis Blanchard
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.