LWN: Comments on "Receive flow steering"

Receive flow steering

smasetty — Thu, 03 Apr 2014 18:11:44 +0000

What is the true benefit of RFS vs RPS. In the kernel documentation section, I see that the author talks about data cache hitrate, I am trying to understand what this really means and how this would be truly beneficial over RPS. Any leads here would be helpful. Thanks

Receive flow steering

ZhuYanhai — Sat, 06 Aug 2011 02:41:26 +0000

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.

Receive flow steering

SEJeff — Tue, 03 Aug 2010 14:15:34 +0000

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

cventers — Thu, 08 Apr 2010 16:57:57 +0000

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

clugstj — Thu, 08 Apr 2010 13:36:37 +0000

As long as there is a switch to turn this thing off. Just because Google is using it doesn't mean it is good for all workloads.

Receive flow steering

intgr — Thu, 08 Apr 2010 07:44:10 +0000

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.