[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Feb 2007 20:06:31 +0100
From: Andi Kleen <ak@...e.de>
To: Rick Jones <rick.jones2@...com>
Cc: Linux Network Development list <netdev@...r.kernel.org>
Subject: Re: "meaningful" spinlock contention when bound to non-intr CPU?
>
> 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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists