Re: Question about xentrace to trace s_time_t type of data

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Sat, Aug 23, 2014 at 11:24:21PM -0400, Meng Xu wrote:
> Hi,
> 
> I'm trying to trace the scheduler-specific events for debug purpose by
> using xentrace (instead of using printk). I read the trace code in credit
> and credit2 scheduler (sched_credit.c and sched_credit2.c) and "followed"
> the way credit2 wrote.
> 
> I added the following code into the burn_budget() in my scheduler file,
> sched_rt.c:
> 
>         /* TRACE */
> 
>         {
> 
>             struct {
> 
>                 unsigned dom:16,vcpu:16;
> 
>                 s_time_t cur_budget;
> 
>             } d;
> 
>             d.dom = svc->vcpu->domain->domain_id;
> 
>             d.vcpu = svc->vcpu->vcpu_id;
> 
>             d.cur_budget = svc->cur_budget;
> 
>             trace_var(TRC_RT_BUDGET_REPLENISH, 1,
> 
>                       sizeof(d),
> 
>                       (unsigned char *) &d);

You put the virtual address addresss of your 'd' structure
that is on the stack in the trace file. That does not contain any
data except an address.

What you need to do is to put the data as such:

	uint32_t dom_vcpu;

	dom_vcpu = srv->vcpu->domain->domain_id;
	dom_vcpu |= (svc->vcpu->vcpu_id << 16);
	TRACE_2D(TRC_RT_BUDGET_REPLENISH, dom_vcpu, svc->cur_budget);

> 
>         }
> 
> ​The result I got from "xenanalyze --dump-all"​ for this event is (I only
> show one entry):
> 
> ]  0.285656366 x-|- d0v1   22804(2:2:804) 4 [ 00010000 ffff82d0 003d0900
> 00000000 ]
> 
> ​What I'm confused is the meaning of "[ 00010000 ffff82d0 003d0900 00000000
> ]":
> 
> I can understand that 00010000 represents dom 0's vcpu 1. But I don't know
> how to interpret the rest of numbers "ffff82d0 003d0900 00000000".

It is a virtual address.
> 
> The cur_budget traced should always be 4000000. So the expected result
> should be the hex value of 4000000.
> 
> *My question is:*
> 1) How should I interpret the    "ffff82d0 003d0900 00000000 " to be
> "4000000"?
> 2) Why does it has three more 32bits in "[ 00010000 ffff82d0 003d0900
> 00000000 ]" instead of just two? (since s_time_t is a signed 64 bit type)
> 
> It seems that xentrace just dump this struct d to a file and xenalyze just
> print it out one by one (and each item is 32bit). In my opinion, the output
> in [ ... ]​ should have only three 32bit-size fields instead of 4. I'm not
> sure where it goes wrong.
> 
> I also tried to change the struct d to
> 
>  struct {
> 
>                 unsigned dom:16,vcpu:16;
> 
>                 unsigned cur_budget_lo;
> 
>                 unsigned cur_budget_hi;
> 
>             } d;
> ​and it give me expected output, which has only three 32bit-size fields in
> [ ... ] in  xenalyze's output​.
> 
> So I'm guessing I should not use a field larger than 32bit in the trace
> struct d. But I'm not sure about the reason. Could any one give me some
> insight?
> 
> Thank you very much for your time and help in this question!
> 
> Best,
> 
> Meng
> 
> 
> -----------
> Meng Xu
> PhD Student in Computer and Information Science
> University of Pennsylvania

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel