Re: [Xenomai-core] [RFC] in-kernel timer benchmark

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka wrote:
> Hi all,
> 
> this is fully working proposal how to re-enable in-kernel timer latency
> benchmarks.
> 
> More precisely, it adds a new RTDM device "rtbenchmark<X>" (and also a
> new RTDM class) which can execute either a kernel task or timer
> periodically. The benchmark device generates all the usual latency data
> which can be retrieved from userspace via IOCTLs. I patched the existing
> latency tool to open the device and read the data from there instead of
> running its own latency task.
> 
> README for a quick test:
> 
>  o apply patch and rebuild everything (don't forget to re-prepare the
>    kernel and also call scripts/bootstrap, I added some files)
> 
>  o load xeno_timerbench (+ xeno_native, xeno_rtdm, ...)
> 
>  o run "latency -D0" to start in-kernel timer task test on device
>    "rtbenchmark0"
> 
>  o run "latency -D0 -t" to start in-kernel timer handler test (i.e.
>    without scheduling latency) on device "rtbenchmark0"
> 

Worked like a charm here.

> This is rather fresh code, handle with care! ;) Moreover, I would like
> to hear your comments if the extension of the latency tool is the right
> way to got or if we better split things up. The problem I see is that
> this patch makes latency depend on xeno_rtdm being loaded.
>

IMO, using RTDM here is definitely the right thing, and depending on it 
for the purpose of benchmarking is acceptable if we admit that 
additional and more complex benchmarks we may provide in the future will 
most likely benefit from using RTDM as a mean to exchange data and get 
control requests from user-space. Better not having to invent some 
braindamage FIFO-based messaging protocol each time we want to enrich 
the benchmark/test collection anyway. Production systems will likely 
don't care about the benchmark suite, so configuring out RTDM if 
otherwise unneeded would still be a no-brainer.

On the split/no-split issue, I'd keep it the way you crafted it, i.e. 
both tests integrated. After all, they both measure the same latencies 
(pure timer test option put aside) even if they happen to do the 
measurements in different exec contexts. I will have two remarks though:

- a clearer message upon failure to start the kernel-based test (likely 
due to the absence of the benchmark module) should be sent. Some hint 
telling the user that "modprobe xeno_timerbench?" would not be a bad 
idea to issue would likely be useful.

- some information when starting/running? the current test that tells us 
which benchmark is currently running.

> PS: I likely broke src/testsuite/latency/runinfo.

This patch should do it, whether the listed features are available as 
modules or statically bound to the kernel:

-latency:rtdm+native:!./latency;popall:control_c
+latency:rtdm+native+timerbench:!./latency;popall:control_c

-- 

Philippe.