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

[Rick Jones <rick.jones2@hp.com>]

> 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