-Whenever a user-space thread (real-time or not) invokes ‘popen (“someCommandA”, “r”)’, other user-space threads (real-time or not) get starved out for various ranges of time (upwards of ~350ms).
-Using ‘perf timechart record sleep 10’ – I discovered that the ~350ms delay is coming from ‘someCommandA’ being decompressed. If ‘someCommandA’ is run again then there is no noticeable delay because ‘someCommandA’ is now cached.
-Running ‘echo 3 > /proc/sys/vm/drop_caches’ – will cause the delay again when invoking the same popen() call.
-‘uname -a’ - Linux myTarget 4.4.6-at1 #2 Mon May 15 19:58:13 UTC 2017 mips GNU/Linux
-I’ve attached a patch (squashfs-xz.patch) against the 4.4.6 kernel that fixes the issue by adding a single cond_resched() call.
-I’ve no idea if this is a proper place for a scheduler call, maybe more are needed elsewhere, and if there are alternatives in helping the decompression play nice with user-space threads.
-If the kernel is compiled with preemption enabled (CONFIG_PREEMPTION=y) – the issue goes away entirely in our environment.
-The ~350ms thread starvation delays are too long for our environment.
-I’m afraid that if larger executables need to get decompressed, the thread starvation delays will just get much worse.
Thanks in advance,
This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. If you are the intended recipient, please be advised that the content of this message is subject to access, review and disclosure by the sender's
e-mail System Administrator.