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

Date:	Fri, 02 Feb 2007 12:41:03 -0800
From:	Rick Jones <rick.jones2@...com>
To:	Andi Kleen <ak@...e.de>
Cc:	Linux Network Development list <netdev@...r.kernel.org>
Subject: Re: "meaningful" spinlock contention when bound to non-intr CPU?

> Yes the wakeup happens deep inside the critical section and if the process
> is running on another CPU it could race to the lock.
> 
> Hmm, i suppose the wakeup could be moved out, but it would need some 
> restructuring of the code. Also to be safe the code would still need
> to at least hold a reference count of the sock during the wakeup, and
> when that is released then you have another cache line to bounce,
> which might not be any better than the lock. So it might not be
> actually worth it.
> 
> I suppose the socket release could be at least partially protected with
> RCU against this case so that could be done without a reference count, but 
> it might be tricky to get this right.
> 
> Again still not sure it's worth handling this.

Based on my experiments thusfar I'd have to agree/accept (I wasn't 
certain to begin with - hence the post in the first place :)  but I do 
need/want to see what happens with a single-stream through a 10G NIC - 
on the receive side at least with a 1500 byte MTU.

I was using the burst-mode aggregate RR over the 1G NICs to get the CPU 
util up without need for considerable bandwidth, since the system 
handled 8 TCP_STREAM tests across the 8 NICs without working-up a sweat. 
  I suppose I could instead chop the MTU on the 1G NICs and use that to 
increase the CPU util on the receive side.

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