From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v2 15/16] xenalyze: handle RTDS scheduler events Date: Thu, 18 Feb 2016 17:06:46 +0000 Message-ID: <56C5FA26.6060801@citrix.com> References: <20160216180550.27876.22680.stgit@Solace.station> <20160216181322.27876.60708.stgit@Solace.station> <56C5E32C.5070204@citrix.com> <1455814938.7213.17.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aWS2W-0001Vf-S5 for xen-devel@lists.xenproject.org; Thu, 18 Feb 2016 17:06:53 +0000 In-Reply-To: <1455814938.7213.17.camel@citrix.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: Dario Faggioli , xen-devel@lists.xenproject.org Cc: Olaf Hering , Wei Liu , Ian Campbell , George Dunlap , Tianyang Chen , Ian Jackson , Meng Xu List-Id: xen-devel@lists.xenproject.org On 18/02/16 17:02, Dario Faggioli wrote: > On Thu, 2016-02-18 at 15:28 +0000, George Dunlap wrote: >> On 16/02/16 18:13, Dario Faggioli wrote: >>> --- >>> tools/xentrace/xenalyze.c | 59 >>> +++++++++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 59 insertions(+) >>> >>> diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c >>> index 8f97f3a..dd21229 100644 >>> --- a/tools/xentrace/xenalyze.c >>> +++ b/tools/xentrace/xenalyze.c >>> @@ -7828,6 +7828,65 @@ void sched_process(struct pcpu_info *p) >>> r->rq_avgload, r->b_avgload); >>> } >>> break; >>> + /* RTDS (TRC_RTDS_xxx) */ >>> + case TRC_SCHED_CLASS_EVT(RTDS, 1): /* TICKLE */ >>> + if(opt.dump_all) { >>> + struct { >>> + unsigned int cpu:16; >>> + } *r = (typeof(r))ri->d; >>> + >>> + printf(" %s rtds:runq_tickle cpu %u\n", >>> + ri->dump_header, r->cpu); >>> + } >>> + break; >>> + case TRC_SCHED_CLASS_EVT(RTDS, 2): /* RUNQ_PICK */ >>> + if(opt.dump_all) { >>> + struct { >>> + unsigned int vcpuid:16, domid:16; >>> + unsigned int cur_dl_lo, cur_dl_hi; >>> + unsigned int cur_bg_lo, cur_bg_hi; >>> + } *r = (typeof(r))ri->d; >>> + uint64_t dl = (((uint64_t)r->cur_dl_hi) << 32) + >>> r->cur_dl_lo; >>> + uint64_t bg = (((uint64_t)r->cur_bg_hi) << 32) + >>> r->cur_bg_lo; >> >> Why are you doing this, instead of just using uint64_t? >> > It was to make the struct in sched_rt.c and here exactly match, for > ease of someone reading both the pieces of code at the same time, to > understand what's being printed. > > However, yes, using uint64_t is probably equally understandable, and > more readable in case one only look at this code, so I can change this > (and resend). Hrm, well perhaps having the struct match exactly is better. I think most of these patches can be checked in now. What about checking in the other patches, then sending a follow-up series with the struct changed in the scheduler, and then this patch with the resulting changes? -George