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