Receive flow steering

Posted Apr 8, 2010 7:44 UTC (Thu) by intgr (subscriber, #39733)
Parent article: Receive flow steering

Wouldn't this cause problems for single-threaded applications? Could the packet receiver thread repeatedly push the actual process to a different processor like this:

1. Daemon gets scheduled to processor A
2. All incoming packets are steered to processor A
3. Processor gets loaded due to processing of incoming packets
4. Scheduler decides that the daemon could get more work done and reschedules it to processor B
5. Repeat

So the daemon and packet processing thread would be playing cat-and-mouse and repeatedly jumping through different processors.

I guess for just plain TCP, the processing overhead can be quite low, but if you add iptables processing, packet capturing etc, it can become significant.

Receive flow steering

Posted Apr 8, 2010 16:57 UTC (Thu) by cventers (guest, #31465) [Link] (1 responses)

How often does a reschedule happen these days? As far as I can last remember, the kernel doesn't do it more than a handful of times per second, right?

Receive flow steering

Posted Aug 3, 2010 14:15 UTC (Tue) by SEJeff (guest, #51588) [Link]

It completely depends on your hardware, and how your application works.

watch -n1 cat /proc/interrupts

Look for the line that says "Rescheduling interrupts". If your apps are loading up with some sort of io such as sssd block io or very fast network io, the scheduler tends to flip out. Thats causes your app to slow down due to being rescheduled. The solution is to setup the affinity of your block devices, network cards, or applications.

In short... depending on your hardware and applications, it can still very much be an issue.

Receive flow steering

Posted Aug 6, 2011 2:41 UTC (Sat) by ZhuYanhai (guest, #44977) [Link]

If what you said is true, the similar thing will still happen to a single process without rps/rfs or even network.

1. Daemon gets scheduled to processor A
2. processor A get very busy.
3. Scheduler decides that the daemon could get more work done and reschedules it to processor B
4. Repeat

So I think the scheduler should already have some methods to detect and prevent such thrashing.