[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3 of 3] xen: sched_credit: add some tracing
On 05/12/12 12:15, Dario Faggioli wrote: But if there is a call to an opaque function (any function the compiler doesn't "know" what it does in the current compile unit - or one where the compiler can't determine that the global variable isn't being modified, e.g. anything that uses pointers the compiler can't trace, etc) in between, the compiler must NOT move the actual read of a global variable. So it would be worth checking the compile output.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. -- Mats 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? Dario _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |