Re: New LTP test feature [Hard Real Time Linux Testing]
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: New LTP test feature [Hard Real Time Linux Testing]
by Darren Hart
::
Rate this Message:
|
|
|
Re: New LTP test feature [Hard Real Time Linux Testing]
by Christian Di Biagio
::
Rate this Message:
|
|
|
Re: New LTP test feature [Hard Real Time Linux Testing]
by Subrata Modak
::
Rate this Message:
|
|
|
Re: New LTP test feature [Hard Real Time Linux Testing]
by Luca Recchia
::
Rate this Message:
Dear All,
just some details about our test. We're actually dealing with Hard Real-Time problems (on x86) and we need a way to measure latencies in the IRQ handling kernel flow-paths. We do not only need to measure the global (from the rise of an interrupt to its complete management) IRQ handling latency, but also the intermediate (inter-function) latency values. Our main objective is to evaluate Hard Real-Time feautures like predictability and time latency of IRQ response and IRQ management flow. The kernel patch and the modules we have developed are in this direction. The patch allows us to measure (with little overhead) the execution times between the main functions of the IRQ management flow. The modules read the values we measure and place them into proc fs (in a more readable manner). All time-values that are taken in the test are measured by reading the TSC register. Both the user space task and the kernel IRQ management flow-path should be bound on one processor, so to avoid discrepancies between different TSC reads on different CPUs. The test is composed by a user space application which is waiting (with a blocking read on /dev/rtc) for RTC interrupts. We re-program the RTC device to launch interrupts at fixed frequency. First fo all the user space test application set the real time priority and the real time policy SCHED_FIFO of the user task, then re-program the RTC device to launch interrupts at fixed frequency, and go to sleep waiting for RTC interrupt. Immediately after being woke up, the user space test application performs a TSC read, which constitutes the final measure of the IRQ management flow. Furthermore this read helps in telling kernel test latencies from spurious kernel inter-function latencies that may occur before the beginning of the test. When the test is over the user apllication print the TSC values on the console. The patch we introduce in the kernel is able to record up to SAMPLES samples of inter-function latencies throughout the kernel path activated by RTC interrupt management flow-path. When the test is over, it is possible to read the inter-function latencies (sampled in the kernel) through the proc fs, using "delta_read_irq" and "irq_latencies_tsc" modules. The "delta_read_irq" module is used to read the inter-function latencies values as the max, min, and total TSC cycles elapsed during the measured intervals. With the "irq_latencies_tsc" module it is possible to read the TSC values taken inside IRQ flow-path functions. By comparing these values with those obtained in the user space application, one can evaluate the whole latencies in the IRQ management flow (from the arrival of an hardware interrupt to the system, to the beginning of the test application). From the analisys of these results we can estimate the worst-case latency and the periodic jitter of an interrupt management flow-path. We are also able to evaluate the required (re)scheduling effort and inter-function latencies. The execution-jitter of the kernel paths we analyze is our measure to evaluate the predictability of "end-to-end" IRQ management (from the arrival of an hardware interrupt to the system, to the beginning of the test application). The measured jitter is the standard deviation of the sampled latencies, relatively to their mean. At the moment, we make use of a spreadsheet to evaluate std.deviation, worst, best and average inter-function and end-to-end latencies. We build these results using 1000 sampled latency values (these values are obtained through the module "irq_latencies_tsc" and through the user space application). It is important to note that the samples we measure in the kernel are in clock cycle unit and we have to transform them into time unit. The resolution of the measure heavily depends on the CPU frequency and on the time spent in reading the TSC. We have estimate for our measure a base definition of 10 ns. The test is not yet automated, and doesn't respect LTP's requirement. At the moment it is just a quite usable tool that is being mainly use as a base comparison between Vanilla kernel and RT kernel project (http://www.eu.kernel.org/pub/linux/kernel/projects/rt/). Regards, Luca Recchia 2008/6/16 Darren Hart <dvhltc@...>:
------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
|
|
Re: New LTP test feature [Hard Real Time Linux Testing]
by Luca Recchia
::
Rate this Message:
Dear All,
just some details about our test. We're actually dealing with Hard Real-Time problems (on x86) and we need a way to measure latencies in the IRQ handling kernel flow-paths. We do not only need to measure the global (from the rise of an interrupt to its complete management) IRQ handling latency, but also the intermediate (inter-function) latency values. Our main objective is to evaluate Hard Real-Time feautures like predictability and time latency of IRQ response and IRQ management flow. The kernel patch and the modules we have developed are in this direction. The patch allows us to measure (with little overhead) the execution times between the main functions of the IRQ management flow. The modules read the values we measure and place them into proc fs (in a more readable manner). All time-values that are taken in the test are measured by reading the TSC register. Both the user space task and the kernel IRQ management flow-path should be bound on one processor, so to avoid discrepancies between different TSC reads on different CPUs. The test is composed by a user space application which is waiting (with a blocking read on /dev/rtc) for RTC interrupts. We re-program the RTC device to launch interrupts at fixed frequency. First fo all the user space test application set the real time priority and the real time policy SCHED_FIFO of the user task, then re-program the RTC device to launch interrupts at fixed frequency, and go to sleep waiting for RTC interrupt. Immediately after being woke up, the user space test application performs a TSC read, which constitutes the final measure of the IRQ management flow. Furthermore this read helps in telling kernel test latencies from spurious kernel inter-function latencies that may occur before the beginning of the test. When the test is over the user apllication print the TSC values on the console. The patch we introduce in the kernel is able to record up to SAMPLES samples of inter-function latencies throughout the kernel path activated by RTC interrupt management flow-path. When the test is over, it is possible to read the inter-function latencies (sampled in the kernel) through the proc fs, using "delta_read_irq" and "irq_latencies_tsc" modules. The "delta_read_irq" module is used to read the inter-function latencies values as the max, min, and total TSC cycles elapsed during the measured intervals. With the "irq_latencies_tsc" module it is possible to read the TSC values taken inside IRQ flow-path functions. By comparing these values with those obtained in the user space application, one can evaluate the whole latencies in the IRQ management flow (from the arrival of an hardware interrupt to the system, to the beginning of the test application). From the analisys of these results we can estimate the worst-case latency and the periodic jitter of an interrupt management flow-path. We are also able to evaluate the required (re)scheduling effort and inter-function latencies. The execution-jitter of the kernel paths we analyze is our measure to evaluate the predictability of "end-to-end" IRQ management (from the arrival of an hardware interrupt to the system, to the beginning of the test application). The measured jitter is the standard deviation of the sampled latencies, relatively to their mean. At the moment, we make use of a spreadsheet to evaluate std.deviation, worst, best and average inter-function and end-to-end latencies. We build these results using 1000 sampled latency values (these values are obtained through the module "irq_latencies_tsc" and through the user space application). It is important to note that the samples we measure in the kernel are in clock cycle unit and we have to transform them into time unit. The resolution of the measure heavily depends on the CPU frequency and on the time spent in reading the TSC. We have estimate for our measure a base definition of 10 ns. The test is not yet automated, and doesn't respect LTP's requirement. At the moment it is just a quite usable tool that is being mainly use as a base comparison between Vanilla kernel and RT kernel project (http://www.eu.kernel.org/pub/linux/kernel/projects/rt/). Regards, Luca Recchia 2008/6/25 Subrata Modak <subrata@...>:
------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Ltp-list mailing list Ltp-list@... https://lists.sourceforge.net/lists/listinfo/ltp-list |
|
|
Re: New LTP test feature [Hard Real Time Linux Testing]
by Subrata Modak
::
Rate this Message:
|
|
|
Re: New LTP test feature [Hard Real Time Linux Testing]
by Christian Di Biagio
::
Rate this Message:
|
test_irq.tar.bz2 (33K) 
| Free Forum Powered by Nabble | Forum Help |