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

Date:	Thu, 27 Jun 2013 13:46:58 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Shawn Bohrer <sbohrer@...advisors.com>
CC:	netdev@...r.kernel.org
Subject: Re: Understanding lock contention in __udp4_lib_mcast_deliver

On 06/27/2013 01:20 PM, Shawn Bohrer wrote:
> On Thu, Jun 27, 2013 at 12:58:39PM -0700, Rick Jones wrote:
>> Are there other processes showing _raw_spin_lock time?  It may be
>> more clear to add a --sort symbol,dso or some such to your perf
>> report command.  Because what you show there suggests less than 1%
>> of the active cycles are in _raw_spin_lock.
>
> You think I'm wasting time going after small potatoes huh?

Perhaps.  I also find it difficult to see the potatoes' (symbols') big 
picture in perf's default sorting :)

> On a normal system it looks like it is about .12% total which is
> indeed small but my thinking was that I should be able to make that
> go to 0 easily by ensuring we use unique ports and only have one
> socket per multicast addr:port.  Now that I've failed at making it go
> to 0 I would mostly like to understand what part of my thinking was
> flawed. Or perhaps I can make it go to zero if I do ...

How do you know that time is actually contention and not simply acquire 
and release overhead?

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