Re: "meaningful" spinlock contention when bound to non-intr CPU?

[Andi Kleen <ak@suse.de>]

> 
> The meta question behind all that would seem to be whether the scheduler 
> should be telling us where to perform the network processing, or should 
> the network processing be telling the scheduler what to do? (eg all my 
> old blathering about IPS vs TOPS in HP-UX...)

That's an unsolved problem.  But past experiments suggest that giving
the scheduler more imperatives than just "use CPUs well" are often net-losses.

I suspect it cannot be completely solved in the general case. 

> Well, yes and no.  If I drop the "burst" and instead have N times more 
> netperf's going, I see the same lock contention situation.  I wasn't 
> expecting to - thinking that if there were then N different processes on 
> each CPU the likelihood of there being a contention on any one socket 
> was low, but it was there just the same.
> 
> That is part of what makes me wonder if there is a race between wakeup 

A race?

> and release of a lock.

You could try with echo 1 > /proc/sys/net/ipv4/tcp_low_latency.
That should change RX locking behaviour significantly.

-Andi