in-kernel timer benchmark
RFC 1/1 in-kernel timer benchmark
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"
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.
Jan
PS: I likely broke src/testsuite/latency/runinfo.
rtdm/rtbenchmark.h +121 -0
@@ -0,0 +1,121 @@ +/** +* @file +* Real-Time Driver Model for Xenomai, benchmark device profile header +* +* @note Copyright (C) 2005 Jan Kiszka <[email protected]> +* +* Xenomai is free software; you can redistribute it and/or modify it +* under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License, or +* (at your option) any later version. +* +* Xenomai is distributed in the hope that it will be useful, but +* WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +* General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with Xenomai; if not, write to the Free Software Foundation, +* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. +* +* @ingroup rtbenchmark +*/ + +/*! +* @ingroup profiles +* @defgroup rtbenchmark Benchmark Devices +* +* This group of devices is intended to provide in-kernel benchmark results. +* Feel free to comment on this profile via the Xenomai mailing list +* ([email protected]) or directly to the author ([email protected]). @n +* @n +* +* @par Device Characteristics +* @ref rtdm_device.device_flags "Device Flags": @c RTDM_NAMED_DEVICE, @c RTDM_EXCLUSIVE @n +* @n +* @ref rtdm_device.device_name "Device Name": @c "rtbenchmark<N>", N >= 0 @n +* @n +* @ref rtdm_device.device_class "Device Class": @c RTDM_CLASS_BENCHMARK @n +* @n +* +* @par Supported Operations +* @b Open @n +* Environments: non-RT (RT optional)@n +* Specific return values: none @n +* @n +* @b Close @n +* Environments: non-RT (RT optional)@n +* Specific return values: none @n +* @n +* @b IOCTL @n +* Mandatory Environments: see @ref IOCTLs "below" @n +* Specific return values: see @ref IOCTLs "below" @n +* +* @{ +*/ + +#ifndef _RTBENCHMARK_H +#define _RTBENCHMARK_H + +#include <asm/types.h> +#include <xenomai/rtdm/rtdm.h> + +#define RTBNCH_TIMER_TASK 0 +#define RTBNCH_TIMER_HANDLER 1 + +typedef struct rtbnch_result { +long avg; +long min; +long max; +long overruns; +long test_loops; +}rtbnch_result_t ; + +typedef struct rtbnch_timerconfig { +int mode; +uint64_t period; +int warmup_loops; +int histogram_size; +int histogram_bucketsize; +}rtbnch_timerconfig_t ; + +typedef struct rtbnch_interm_result { +struct rtbnch_result last; +struct rtbnch_result overall; +}rtbnch_interm_result_t ; + +typedef struct rtbnch_overall_result { +struct rtbnch_result result; +long *histogram_avg; +long *histogram_min; +long *histogram_max; +}rtbnch_overall_result_t ; + + +#define RTIOC_TYPE_BENCHMARK RTDM_CLASS_BENCHMARK + + +/*! +* @name Sub-Classes of RTDM_CLASS_BENCHMARK +* @{ */ +#define RTDM_SUBCLASS_TIMER 0 +/** @} */ + + +/*! +* @anchor IOCTLs @name IOCTLs +* Benchmark device IOCTLs +* @{ */ + +#define RTBNCH_RTIOC_INTERM_RESULT \ + _IOWR(RTIOC_TYPE_BENCHMARK, 0x00, struct rtbnch_interm_result) + +#define RTBNCH_RTIOC_START_TMTEST \ + _IOW(RTIOC_TYPE_BENCHMARK, 0x10, struct rtbnch_timerconfig) + +#define RTBNCH_RTIOC_STOP_TMTEST \ + _IOWR(RTIOC_TYPE_BENCHMARK, 0x11, struct rtbnch_overall_result) + +/** @} */ + +#endif /* _RTBENCHMARK_H */
rtdm/rtdm.h +1 -0
@@ -68,6 +68,7 @@#define RTDM_CLASS_CAN 3#define RTDM_CLASS_NETWORK 4#define RTDM_CLASS_RTMAC 5 +#define RTDM_CLASS_BENCHMARK 6/* #define RTDM_CLASS_USB ? #define RTDM_CLASS_FIREWIRE ?
testsuite/latency/latency.c +144 -47
291 lines not on this page · raw message
testsuite/latency/Makefile.am +1 -0
@@ -10,6 +10,7 @@ latency_LDADD = \ ../../skins/native/libnative.la \ + ../../skins/rtdm/librtdm.la \ -lpthread -lm install-data-local:
drivers/Kconfig +1 -0
@@ -1 +1,2 @@ source "drivers/xenomai/16550A/Kconfig" +source "drivers/xenomai/benchmark/Kconfig"
drivers/Config.in +1 -0
@@ -8,5 +8,6 @@ mainmenu_option next_comment comment 'Real-time drivers' source drivers/xenomai/16550A/Config.in + source drivers/xenomai/benchmark/Config.in endmenu fi
drivers/benchmark/Kconfig +7 -0
@@ -0,0 +1,7 @@ +config XENO_DRIVERS_TIMERBENCH + depends on XENO_SKIN_RTDM + tristate "Timer benchmark driver" + default n + help + Kernel-based benchmark driver for timer latency evaluation. + See testsuite/latency for a possible front-end.
drivers/benchmark/timerbench.c +498 -0
498 lines not on this page · raw message
drivers/benchmark/Config.in +5 -0
@@ -0,0 +1,5 @@ +# +# Xenomai configuration for Linux v2.4 +# + +dep_tristate 'Timer benchmark driver' CONFIG_XENO_DRIVERS_TIMERBENCH $CONFIG_XENO_SKIN_RTDM
drivers/benchmark/Makefile +30 -0
@@ -0,0 +1,30 @@ +ifeq ($(PATCHLEVEL),6) + +# Makefile frag for Linux v2.6 + +obj-$(CONFIG_XENO_DRIVERS_TIMERBENCH) += xeno_timerbench.o + +xeno_timerbench-y := timerbench.o + +else + +# Makefile frag for Linux v2.4 + +O_TARGET := built-in.o + +obj-$(CONFIG_XENO_DRIVERS_TIMERBENCH) := xeno_timerbench.o + +list-multi := xeno_timerbench.o + +xeno_timerbench-objs := timerbench.o + +export-objs := $(xeno_timerbench-objs) + +EXTRA_CFLAGS += -I$(TOPDIR)/include/xenomai/compat + +include $(TOPDIR)/Rules.make + +xeno_timerbench.o: $(xeno_timerbench-objs) + $(LD) -r -o $@ $(xeno_timerbench-objs) + +endif
drivers/Makefile +3 -1
@@ -2,7 +2,7 @@ # Makefile frag for Linux v2.6 -obj-$(CONFIG_XENOMAI) += 16550A/ +obj-$(CONFIG_XENOMAI) += 16550A/ benchmark/ else
@@ -10,6 +10,8 @@ subdir-$(CONFIG_XENO_DRIVERS_16550A) += 16550A +subdir-$(CONFIG_XENO_DRIVERS_benchmark) += benchmark + include $(TOPDIR)/Rules.make endif
Quoted 17 lines · Jan Kiszka
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)
Quoted 8 lines
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.
Quoted 5 lines
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_rtdmbeing 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.
Quoted 1 line
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
Signature · 1 line
Philippe.
Quoted 22 lines · Jan Kiszka
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"
Quoted 7 lines
o run "latency -D0 -t" to start in-kernel timer handler test (i.e. without scheduling latency) on device "rtbenchmark0"
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_rtdmbeing loaded.
I agree with Philippe: having a driver for the various benchmarking needs is a good idea, we could imagine adding ioctls for the various loads, etc... But I would vote for a split between the user-space latency measurement tool and the display tool for kernel-space latency.
A minor issue: in the 2.4 portion of ksrc/drivers/Makefile, should not CONFIG_XENO_DRIVERS_benchmark be replaced with CONFIG_XENO_DRIVERS_TIMERBENCH ?
It is a very interesting tool indeed (especially since I would need such a tool to benchmark the various solutions to improve nucleus timers scalability :). But it would be nice to be able to create several tasks or several timers without having to open one file descriptor by timer/task. Or if you want one file descriptor by timer/task, rt_tmbench_ioctl_nrt should return an error when trying to start the task or timer twice.
Signature · 1 line
Gilles Chanteperdrix.
Quoted 31 lines · Gilles Chanteperdrix
Quoted 22 lines · Jan Kiszka
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"
Quoted 7 lines
o run "latency -D0 -t" to start in-kernel timer handler test (i.e. without scheduling latency) on device "rtbenchmark0"
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_rtdmbeing loaded.
Quoted 5 lines
I agree with Philippe: having a driver for the various benchmarking needs is a good idea, we could imagine adding ioctls for the various loads, etc... But I would vote for a split between the user-space latency measurement tool and the display tool for kernel-space latency.
What's your main concern about the current solution? The need to have RTDM being loaded to start only the userspace test?
If this is the case, do we have some option to only fail when the user actually requests in-kernel tests without any xeno_rtdm being loaded? That means we would somehow have to avoid that the librtdm initialisation fatally fails in this particular use case - hmm, or maybe even in general...
Let's think about this: If there is no xeno_rtdm, then there is also no driver loaded. While we can catch to first case during lib-init, the latter will always trigger later in the program. So, having no xeno_rtdm could also be interpreted by the lib like not having the (every) addressed driver being loaded. I think I should prepare a patch, shouldn't I?
Quoted 3 lines
A minor issue: in the 2.4 portion of ksrc/drivers/Makefile, should not
CONFIG_XENO_DRIVERS_benchmarkbe replaced withCONFIG_XENO_DRIVERS_TIMERBENCH?
Yep, someone was not able to handle search&replace correctly.
Quoted 9 lines
It is a very interesting tool indeed (especially since I would need such a tool to benchmark the various solutions to improve nucleus timers scalability :). But it would be nice to be able to create several tasks or several timers without having to open one file descriptor by timer/task. Or if you want one file descriptor by timer/task,
rt_tmbench_ioctl_nrtshould return an error when trying to start the task or timer twice.
Ok, I will try to reworks this, generating a ready-for-merge patch which will also include Philippe's remarks. No promise if this is going to be a pre-Christmas gift. ;)
Jan
Quoted 7 lines · Jan Kiszka
Quoted 3 lines · Gilles Chanteperdrix
(...) But I would vote for a split between the user-space latency measurement tool and the display tool for kernel-space latency.
What's your main concern about the current solution? The need to have RTDM being loaded to start only the userspace test?
I thought the user-space latency was also an example for the native skin, and had not much in common with the display task for the kernel-space benchmark. But these benchmarks have in fact much in common, and the native skin still has the "satch" demo.
Quoted 9 lines
Quoted 8 lines
It is a very interesting tool indeed (especially since I would need such a tool to benchmark the various solutions to improve nucleus timers scalability :). But it would be nice to be able to create several tasks or several timers without having to open one file descriptor by timer/task. Or if you want one file descriptor by timer/task,
rt_tmbench_ioctl_nrtshould return an error when trying to start the task or timer twice.
Quoted 3 lines
Ok, I will try to reworks this, generating a ready-for-merge patch which will also include Philippe's remarks. No promise if this is going to be a pre-Christmas gift. ;)
Do not bother, since I am the one who need it, I may change it. I will follow-up with a new proposal.
Signature · 1 line
Gilles Chanteperdrix.