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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 2 Feb 2007 08:47:19 -0800
From:	"Jesse Brandeburg" <jesse.brandeburg@...il.com>
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?

On 2/1/07, Rick Jones <rick.jones2@...com> wrote:
<snip>
> With some help from Lee Schermerhorn and Alan Brunelle I got a lockmeter
> kernel going, and it is suggesting that the greatest spinlock contention
> comes from the routines:
>
> SPINLOCKS         HOLD            WAIT
>    UTIL  CON    MEAN(  MAX )   MEAN(  MAX )(% CPU)     TOTAL NOWAIT SPIN
> RJECT  NAME
>
>    7.4%  2.8%  0.1us( 143us)  3.3us( 147us)( 1.4%)  75262432 97.2%  2.8%
>     0%  lock_sock_nested+0x30
>   29.5%  6.6%  0.5us( 148us)  0.9us( 143us)(0.49%)  37622512 93.4%  6.6%
>     0%  tcp_v4_rcv+0xb30
>    3.0%  5.6%  0.1us( 142us)  0.9us( 143us)(0.14%)  13911325 94.4%  5.6%
>     0%  release_sock+0x120
>    9.6% 0.75%  0.1us( 144us)  0.7us( 139us)(0.08%)  75262432 99.2% 0.75%
>     0%  release_sock+0x30
>
> I suppose it stands to some reason that there would be contention
> associated with the socket since there will be two things going for the
> socket (a netperf/netserver and an interrupt/upthestack) each running on
> separate CPUs.  Some of it looks like it _may_ be inevitable? -
> waking-up the user who will now  be racing to grab the socket before the
> stack releases it? (I may have been mis-interpreting some of the code I
> was checking)
>
> Still, does this look like something worth persuing?  In a past life/OS
> when one was able to eliminate one percentage point of spinlock
> contention, two percentage points of improvement ensued.

Rick, this looks like good stuff, we're seeing more and more issues
like this as systems become more multi-core and have more interrupts
per NIC (think MSI-X)

Let me know if there is something I can do to help.
-
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