Re: [Xenomai-help] AT91SAM9260 latency

[Jan Kiszka <jan.kiszka@domain.hid>]

Gilles Chanteperdrix wrote:
> On Jan 28, 2008 2:46 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> Gilles Chanteperdrix wrote:
>>> On Jan 28, 2008 2:34 PM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> ...
>>>>> The behaviour you get may be due, for instance, to the fact that the
>>>>> processor goes into some sleep mode when idle and to a wake-up
>>>>> latency; if you run some load, there is no wake-up latency. It is hard
>>>>> to say anything. In order to investigate, I would instrument the
>>>>> kernel to trace the irq masking sections.
>>>> Don't we have the I-pipe tracer on this platform?
>>> Unfortunately, the tracer on arm has too much overhead to give
>>> meaningful results.
>> Hmm. Unless the system becomes unusable while running the tracer, I
>> don't see the show-stopper yet. We are looking for an increase of the
>> latency when triggering a certain event. That should remain measurable
>> even if the base latency is far higher than usually.
>>
>> Do you know what makes the tracer so slow?
>>
> 
> I suspected the fact that we disabled and enabled hardware irqs in
> ipipe_get_tsc, but I reimplemented ipipe_get_tsc to not shut
> interrupts off and the overhead of the tracer remains high.

The tracer itself is built upon atomicity through irq disabling, so the
issue is broader - if only playing with irq flags is the problem.

Are there any trivial functions needlessly instrumented that cause too
much overhead? Maybe spending some more "notrace" would help then.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux