Re: [PATCH 3 of 3] xen: sched_credit: add some tracing

[Mats Petersson <mats.petersson@citrix.com>]

On 05/12/12 12:15, 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.
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.

--
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
>