netdev - Re: Understanding lock contention in __udp4_lib_mcast

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] [day] [month] [year] [list]

Message-ID: <1372796198.4979.20.camel@edumazet-glaptop>
Date:	Tue, 02 Jul 2013 13:16:38 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Shawn Bohrer <sbohrer@...advisors.com>
Cc:	Rick Jones <rick.jones2@...com>, netdev@...r.kernel.org
Subject: Re: Understanding lock contention in __udp4_lib_mcast_deliver

On Thu, 2013-06-27 at 17:44 -0500, Shawn Bohrer wrote:
> On Thu, Jun 27, 2013 at 03:03:15PM -0700, Rick Jones wrote:
> > On 06/27/2013 02:54 PM, Shawn Bohrer wrote:
> > >On Thu, Jun 27, 2013 at 01:46:58PM -0700, Rick Jones wrote:
> > >>How do you know that time is actually contention and not simply
> > >>acquire and release overhead?
> > >
> > >Excellent point, and that could be the problem with my thinking.  I
> > >just now tried (unsuccessfully) to use lockstat to see if there was
> > >any contention reported.  I read Documentation/lockstat.txt and
> > >followed the instructions but the lock in question did not appear to
> > >be in the output.  I think I'm going to have to go with the assumption
> > >that this is just acquire and release overhead.
> > 
> > I think there is a way to get perf to "annotate" (iirc that is the
> > term it uses) the report to show hits at the instruction level.
> > Ostensibly one could then look and see how many of the hits were for
> > the acquire/release part of the routine, and how much was for the
> > actual contention.
> 
> Yep, so ~1% of my total time is in _raw_spin_lock and using perf
> annotate it appears that maybe only 5-6% percent of that is actually
> contention and the rest is acquire/release.  Looks like I need to look
> elsewhere for my performance improvements.  Thanks Rick for your help!
> Below is the output of perf annotate if your curious.

It seems multicast reception could benefit from the 'hcount' infra added
in commit fdcc8aa953a1123 ("udp: add a counter into udp_hslot")

That is : if udp hash slot has few sockets (apparently in your case, at
most one socket per hash slot), we can perform RCU lookup as in unicast
case.

__udp4_lib_mcast_deliver() had to use a spin_lock() protection because
we had no idea of the number of sockets we could find, as we use a
stack[256 / sizeof(struct sock *)] to hold socket pointers, and one
incoming message had to be delivered exactly once per socket.





--
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