Re: [Xenomai-core] [PATCH 6/6] Introduce IRQ latency benchmark

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

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > > Is there no way to make this code easier to port for example by using
>  > > native or posix services for timings measurement and by abstracting the
>  > > non portable part and moving them to include/asm-i386 ?
>  > 
>  > This tool is intentionally left Xenomai-free. You can put it on any x86
>  > box around (and I assume that there is almost always some...) and run
>  > the test. Thus, no need for a second RT-patched system.
>  > 
>  > Anyway, suggestions or patches to add a porting layer are welcome. The
>  > following points need to be addressed: time measuring, irq protection,
>  > hardware access. I just wonder if this is worth the effort.
> 
> I do not understand: it appears to me that Xenomai trunk does not
> compile on other architectures than x86 when applying the IRQ latency
> benchmark patch. So, something needs to be done. It may be the enabling
> of an automake conditional in configure.in when compiling for x86.
> 

See the patch:

Index: xenomai/src/testsuite/irqbench/Makefile.am
===================================================================
--- /dev/null
+++ xenomai/src/testsuite/irqbench/Makefile.am
@@ -0,0 +1,47 @@
+testdir = $(prefix)/testsuite/irqbench
+
+test_PROGRAMS = irqloop
+
+ifeq ($(XENO_TARGET_ARCH),i386)
+test_PROGRAMS += irqbench
+endif


I just realised that some hint in the documentation that irqbench can
easily be compiled outside Xenomai is required.

>  > 
>  > > 
>  > > Also note that calling printf from a signal handler risk deadlocking if
>  > > the signal handler get called on the return path of the write call that
>  > > take place in the middle of a printf call on the main thread.
>  > > 
>  > 
>  > Ok, then we also need a fix for the latency test (this is where I
>  > grabbed that pattern from). Is there a high risk that this locks up? I
>  > wonder why I never observed or heard of problems with latency.
> 
> The latency test used to deadlock, that is why the summary printed on
> signal is printed on stderr. Unfortunately, there seem to be one display
> left on stdout, so it should still deadlock. The reason why we never see
> the deadlock is (perhaps) that the continuous intermediate results are
> printed on the context of the "display" thread, whereas the termination
> signals are preferably delivered by the kernel to the "main" thread,
> that only calls pause. Which makes the use of stderr in signals handlers
> pointless.
> 
> Anyway, since your program is frequently using printf on the context of
> the main thread, the risk of deadlock is real.
> 

Ok, I'm going to address this.

Thanks for the hint!

Jan


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