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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to