From: George Dunlap <george.dunlap@eu.citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Meng Xu <xumengpanda@gmail.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: Question about xentrace to trace s_time_t type of data
Date: Mon, 1 Sep 2014 16:23:56 +0100 [thread overview]
Message-ID: <54048F8C.5000704@eu.citrix.com> (raw)
In-Reply-To: <20140825133159.GC2527@laptop.dumpdata.com>
On 08/25/2014 02:31 PM, Konrad Rzeszutek Wilk wrote:
> 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.
No; trace_var() takes a pointer to a struct and a size. Meng is
following the example he's seen in sched_credit2.c. :-)
The size of the structure is larger because the structure isn't
"packed": by default it will try to make 64-bit elements 64-bit aligned
by adding in "padding". You can get around this in one of two ways:
1. Re-arranging the elements so they're naturally aligned. In this
case, you could do
struct {
s_time_t cur_budget;
unsigned dom:16, vcpu:16;
} d;
2. Adding "__packed" after "struct". This tells the compiler not to try
to align the bytes according to their size.
That explains why it's 4 words instead of 3, but I'm still a bit
mistified why it's not something like
[ 00010000 <garbage> 40000000 00000000 ]
I guess try with a packed structure and see what you get. :-)
-George
prev parent reply other threads:[~2014-09-01 15:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-24 3:24 Question about xentrace to trace s_time_t type of data Meng Xu
2014-08-25 13:31 ` Konrad Rzeszutek Wilk
2014-08-25 15:14 ` Meng Xu
2014-08-25 15:20 ` Konrad Rzeszutek Wilk
2014-08-25 16:22 ` Meng Xu
2014-08-25 16:39 ` Konrad Rzeszutek Wilk
2014-08-25 19:34 ` Meng Xu
2014-09-01 15:23 ` George Dunlap [this message]
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=54048F8C.5000704@eu.citrix.com \
--to=george.dunlap@eu.citrix.com \
--cc=dario.faggioli@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=xen-devel@lists.xenproject.org \
--cc=xumengpanda@gmail.com \
/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.