Andi Kleen wrote:
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 wasn't thinking about giving the scheduler more imperitives really
(?), just letting "networking" know more about where threads executed
accessing given connections. (eg TOPS)
I suspect it cannot be completely solved in the general case.
Not unless the NIC can peer into the connection table and see where each
connection was last accessed by user-space.
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?
Perhaps a poor choice of words on my part - something along the lines of:
hold_lock();
wake_up_someone();
release_lock();
where the someone being awoken can try to grab the lock before the path
doing the waking manages to release it.
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.
Running the same 8 netperf's with TCP_RR and burst bound to different
CPU than the NIC interrupt, the lockmeter output looks virtually
unchanged. Still release_sock, tcp_v4_rcv, lock_sock_nested at their
same offsets.
However, if I run the multiple-connection-per-thread code, and have each
service 32 concurrent connections, and bind to a CPU other than the
interrupt CPU, the lock contention in this case does appear to go away.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
