From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 3 of 3] xen: sched_credit: add some tracing Date: Wed, 5 Dec 2012 12:25:54 +0000 Message-ID: <50BF3D52.9050403@eu.citrix.com> References: <50BE4AC2.9010507@eu.citrix.com> <1354708472.21632.21.camel@Abyss> <1354708869.15296.173.camel@zakaz.uk.xensource.com> <1354709754.21632.31.camel@Abyss> <1354710048.15296.175.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1354710048.15296.175.camel@zakaz.uk.xensource.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: Ian Campbell Cc: "Keir (Xen.org)" , xen-devel , Dario Faggioli List-Id: xen-devel@lists.xenproject.org On 05/12/12 12:20, Ian Campbell wrote: > On Wed, 2012-12-05 at 12:15 +0000, Dario Faggioli wrote: >> On Wed, 2012-12-05 at 12:01 +0000, Ian Campbell wrote: >>>> As I tried to explain in the comment, I just wanted to avoid checking >>>> for !tb_init_done more than once, as this happens within a loop and, at >>>> least potentially, there may be more CPUs to tickle (and thus more calls >>>> to TRACE_1D). >>> If tb_init_done isn't marked volatile or anything like that isn't the >>> check hoisted out of the loop by the compiler? >>> >> Good point. As they're all macros, yes, I think that is something very >> likely to happen... Although, I haven't checked the generated code, I'll >> take a look. Thanks. >> >>>> I take this comment of yours as you not thinking that is >>>> something worthwhile, right? If so, I can definitely turn this into a >>>> "standard" TRACE_1D() call. >>> Or maybe consider __TRACE_1D and friends which omit the check? >>> >> Mmm... It may well be me, but my >> >> $ grep __TRACE xen/* -R >> >> does not show any results... What am I missing? > I meant to define + use those macros. Well ATM there would be only one user -- and "trace_var(..., sizeof(cpu), &cpu);" is probably just as pretty as __TRACE_1D(..., cpu). I wouldn't oppose such a patch, but I don't think it should be required until we want to use "__TRACE_(N>2)D". -George