Michael Tasche
|
Kernel memory manager disturbs Realtime!
|
Michael Tasche
02/26/2015 12:44 PM
post113384
|
Kernel memory manager disturbs Realtime!
Hi all,
there seems to be a strange issue in the kernel regarding big memory allocations.
Attached you will find a small program, which measures the cycle time of a high priority cycle thread:
# tjitter
Syntax: tjitter <cycletime_in_nsec> <prio> [<malloc_size>[k|m|g]]
If you leave the last parameter empty, you can try to disturnb the cycle with other system actions.
If not, the tool will malloc(), memset() and free() a buffer from time to time.
I testet it on several systems:
CPU's: x86, armle, armle.v7 and ppcbe.
Kernel: 6.5.0sp1, 6.6.0 and 8.0.0(BB Z10)
I used a cycle of 1 millisecond, a prio of 255 and a buffer of 300 MB.
The tool displays your system ticksize, so you can sync you cycle time with it.
e.g. Standard bios PC with 6.5.0sp1:
# tjitter 999987 255 300m
Using Cycletime of 999.987 usec at thread prio 255. Systemtick is 999.987 usec
Tick:0 Lost Ticks:0 Cycle Time/usec: Act=0 Avg=0 Max=0
Tick:1002 Lost Ticks:0 Cycle Time/usec: Act=987 Avg=987 Max=992
Tick:2003 Lost Ticks:0 Cycle Time/usec: Act=987 Avg=987 Max=994
...
I saw cycle delay's up to 10 ms on a 2 GHZ dualcore.
If you make a kernel event trace, you will find a procnto thread at the low prio, servicing the memory allocations by
jumping for long intervals in the kernel (Ring0).
This long kernel pathes are the reason for the big cycle-jitter.
There seems to be something wrong with the kernel premtion.
Any idea's from the kernel guru's?
Kind Regards
Michael
|
|
|