I have a kind of a complex application, which uses heavy IO: it includes ffmpeg
and doing video transcoding (by software, no HW-acceleration is available).
This might be unimportant, but I wanted to emphasize it.
All video transcoding functions are working on their own std::thread
, and using libev
for IO management.
Hardware details:
- CPU architecture is ARM
- OS is Debian.
Now, I'm trying to use ping
to check if a particular server is available. I found ping's open source, and included in the application. This is running an a completely different std::thread
.
Problem:
If there is no video-transcoding in progress, ping function works as intended. However, when there is a CPU-intensive transcoding, ping function 99% returns with timeout. I suspect there is some kind of IO starving, so I deep dived into pings source:
I found out that ping uses the old select
function call to detect if there is an I/O available. I was almost sure this causing the problem, and I have refactored the code: dropped select
, and put libev
into action.
But unfortunately the starving still stays the same.
I have almost accepted this, as the video transcoding really puts a huge load onto the CPU (70-80%).
But, if I run my application from an SSH session #A, and run ping from another SSH session #B, my application can do the transcoding, and there is no singe lost packet from ping on session #B.
Conclusion:
The hardware seems capable of running my heavy application in parallel with ping.
Question:
I am really curious of:
- Is there a limitation per process on Linux on how many IOs can the process use? (I guess, but how can I know this limitation? How can I raise this limitation? How can I check current usage?)
- If there is not any problems with IO limitation, what else can cause this kind of "starving-like" problems between
std::threads
? (Anyway, pings thread seems not blocking, as it receives the timeout. It just does not receive a free IO operation) More accurate: ping actually CAN send out packets, but they just do not seem arriving back. And I am almost sure those ping packets replys are coming back, just my application is not getting a green light for READ operation.