Jan Kiszka wrote:
Hi all,

this is fully working proposal how to re-enable in-kernel timer latency

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

 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:




Xenomai-core mailing list

Reply via email to