From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Question about xentrace to trace s_time_t type of data Date: Mon, 1 Sep 2014 16:23:56 +0100 Message-ID: <54048F8C.5000704@eu.citrix.com> References: <20140825133159.GC2527@laptop.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XOTSn-0001Yy-Ar for xen-devel@lists.xenproject.org; Mon, 01 Sep 2014 15:24:13 +0000 In-Reply-To: <20140825133159.GC2527@laptop.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk , Meng Xu Cc: "xen-devel@lists.xenproject.org" , Dario Faggioli List-Id: xen-devel@lists.xenproject.org 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 40000000 00000000 ] I guess try with a packed structure and see what you get. :-) -George