IO-starving causes?

46 Views Asked by At

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.
0

There are 0 best solutions below