|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 03/15] xen/tools: tracing: several improvements on IRQs tracing
>>> On 08.06.17 at 16:53, <george.dunlap@xxxxxxxxxx> wrote:
> On 07/06/17 16:58, Jan Beulich wrote:
>>>>> On 07.06.17 at 17:45, <dario.faggioli@xxxxxxxxxx> wrote:
>>> On Wed, 2017-06-07 at 09:05 -0600, Jan Beulich wrote:
>>>>>>> On 01.06.17 at 19:33, <dario.faggioli@xxxxxxxxxx> wrote:
>>>>> @@ -884,9 +919,13 @@ void do_IRQ(struct cpu_user_regs *regs)
>>>>> desc->rl_quantum_start = now;
>>>>> }
>>>>>
>>>>> - tsc_in = tb_init_done ? get_cycles() : 0;
>>>>> + if ( unlikely(tb_init_done) )
>>>>> + {
>>>>> + __trace_var(TRC_HW_IRQ_GUEST, 0, sizeof(irq), &irq);
>>>>> + tsc_in = get_cycles();
>>>>> + }
>>>>> __do_IRQ_guest(irq);
>>>>> - TRACE_3D(TRC_HW_IRQ_HANDLED, irq, tsc_in, get_cycles());
>>>>> + trace_irq_handled(irq, get_cycles() - tsc_in);
>>>>> goto out_no_end;
>>>>> }
>>>>
>>>> Before this change, the get_cycles() invocation was after
>>>> the tb_init_done check. Now you move it ahead of it (as
>>>> the function arguments are evaluated before executing the
>>>> function body) - are you sure all compiler versions will suitably
>>>> re-order this?
>>>>
>>>> Additionally I'm afraid this will trigger compiler warnings on at
>>>> least some compiler versions, as tsc_in is now possibly
>>>> uninitialized (and there's no clear way to disprove this for the
>>>> compiler, again because function arguments are being
>>>> evaluated before the function body is reached).
>>>>
>>> I understand and (now that I see it) agree with your remark on when
>>> get_cycles() is called. I'll reorganize things so that the patched
>>> behavior matches the existing one.
>>>
>>> OTOH, I'm not sure I see the "potentially uninitialized" issue for
>>> tsc_in, but since I'm reworking the code, I'll keep that in mind too.
>>
>> You initialize tsc_in only when tb_init_done is set, but you use
>> it without that conditional. And even if you used it under that
>> same conditional, older compiler versions aren't able to track
>> that fact (same conditional) and raise a warning anyway.
>
> This patch changes thing to initialize tsc_in on declaration (at the top
> of the function).
Oh, it's only now that I actually see an initializer is being added.
I'm sorry for the noise then.
> If we want to keep the compiler "uninitialized variable" analysis
> around, that would have to go away and we'd want to do something like
> was there before. (I'm ambivalent about it, but I know Jan likes it.)
No, I'm fine with the change. I was just being blind.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |