Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction

Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction

[Hollis Blanchard]

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

Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction

[Christian Ehrhardt]

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

Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction

[Hollis Blanchard]

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

Re: [kvm-ppc-devel] [PATCH] [2/3] kvmppc: full instruction

[Hollis Blanchard]

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