We are running a real-time process on a non real-time kernel (CentOS 6), and this is probably not going to change.
We have a streaming video application that requires about 500 MB/s of PCIe traffic from a custom FPGA continuously for 1.5 hours at a time. The application works pretty well - most of the time. However, we've had situations where it appears that the kernel just stops responding to servicing PCIe or memory requests for up to 500 milliseconds at a time. This appears to happen during bursty file IO from another thread. I've found it impossible to try to replicate this problem by just doing lots of dummy file IO from user space while the main application is running.
Is there a way to force (simulate) a global "freeze" of the Linux kernel (in particular, stopping PCIe or all DDR3 memory accesses or something like that) so that we can reproduce this problem?
We have buffering up to 10 milliseconds implemented right now into internal FPGA memory, but that is not enough. We can buffer to FPGA DDR3 and then dump to the host, but we need a method to test this new feature under duress.
We don't want the kernel to freeze or lock up permanently. We would like the ability to set the time interval.
I am looking for something along the lines of writing magic values to
/proc/sys/vm temporarily that makes the system virtually crawl, and then reverting back after a few hundred milliseconds, but looking at the number of possible ways to break it is not for a newbie like me (https://www.kernel.org/doc/Documentation/sysctl/vm.txt) . Maybe some