Re: [Xen-devel] Question about xentrace to trace s_time_t type of data

[Meng Xu <xumengpanda@xxxxxxxxx>]

Hi Konrad,

2014-08-25 11:20 GMT-04:00 Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>:

On Mon, Aug 25, 2014 at 11:14:52AM -0400, Meng Xu wrote:
> Hi Konrad,
>
> Thank you very much for answering my question!
>
> âI actually have a question regarding to your answer.
>
> Briefly speaking, I'm thinking what you suggests is doing the same (or
> similar) thing as I did? Below is my reason.
>
>
> > >
> > > 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);
> >
>
> âIn file xen/include/xen/trace.h, TRACE_2D is defined as follows:
>
> #define TRACE_2D(_e,d1,d2)Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
>
>Â Â Âdo {Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
>
>Â Â Â Â Âif ( unlikely(tb_init_done) )Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
>
>Â Â Â Â Â{Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
>
>Â Â Â Â Â Â Âu32 _d[2];Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â \
>
>Â Â Â Â Â Â Â_d[0] = d1;Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
>
>Â Â Â Â Â Â Â_d[1] = d2;Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
>
>Â Â Â Â Â Â Â__trace_var(_e, 1, sizeof(_d), _d);Â Â Â Â Â Â Â Â Â\
>
>Â Â Â Â Â}Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â\
>Â Â Â} while ( 0 )â
>
>
>
> âIn the same file, the trace_var() is defined as follows:
>
> static inline void trace_var(u32 event, int cycles, int extra,
>
>Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â const void *extra_data)
>
> {
>
>Â Â Âif ( unlikely(tb_init_done) )
>
>Â Â Â Â Â__trace_var(event, cycles, extra, extra_data);
> }Â Ââ
>
> â
> The description of the function __trace_var(u32 event, bool_t cycles,
> unsigned int extra,const void *extra_data) is in xen/common/trace.c:
>
> /**
>
>Â * __trace_var - Enters a trace tuple into the trace buffer for the current
> CPU.
>
>Â * @event: the event type being logged
>
>Â * @cycles: include tsc timestamp into trace record
>
>Â * @extra: size of additional trace data in bytes
>
>Â * @extra_data: pointer to additional trace data
>
>Â *
>
>Â * Logs a trace record into the appropriate buffer.
>Â */â
>
>
> So I'm thinking what you suggests is doing the same (or similar) thing as I
> did? In addition, from the description of the function __trace_var() , it
> seems I should parse the pointer of the struct d to this function.
>
> âMaybe I misunderstood your suggestion?
>
> Thank you very much for your time!

I have to be honest I hadn't actually dug in what was underneath
the macro. Just been using the macro and it had worked for me.

âThank you for your time, anyway! :-)Â

I think the issue is when I tried to trace a type of data larger than 32bits, such as the type s_time_t, the trace_var() result Âbecomes uninterpretable. Maybe I should never simply pass a type of data larger than 32bit to trace macro, but ÂI don't know (and I hope to know) why. Â:-(

âBest,

Mengâ

-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania

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