Re: [Xenomai-core] [bug] don't try this at home...

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

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> ...
>> Anyway, there seems to be some latency issues pending. I discovered this
>> again with my migration test. Please give it a try on a mid- (800 MHz
>> Athlon in my case) to low-end box. On that Athlon I got peaks of over
>> 100 us in the userspace latency test right on starting migration. The
>> Athlon does not support the NMI watchdog, but on my 1.4 GHz Notebook
>> there were alarms (>30 us) hitting in the native registry during
>> rt_task_create. I have no clue yet if anything is broken there.
> 
> 
> I suspect that rt_registry_enter() is inherently a long operation when
> considered as a non-preemptible sum of reasonably short ones. Since it
> is always called with interrupts enabled, we should split the work in
> there, releasing interrupts in the middle. The tricky thing is that we
> must ensure that the new registration slot is not exposed in a
> half-baked state during the preemptible section.
> 

Grr, I should stop profiling systems which have DEBUG options switched
on (e.g. Xenomain's queue debugging...). This totally skrewed up my
measurings - end of alarm, all fine!

Anyway, keeping the number of ops inside continues lock paths low is a
good thing. But if the task deletions path is already one of the most
critical points, needs some analysis first.

Jan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]