On Wed, 2013-02-27 at 13:04 -0500, David Miller wrote:

From: Eric Dumazet <redacted>
Date: Wed, 27 Feb 2013 09:05:03 -0800

quoted

Processing pure ACK on behalf of the thread blocked in tcp_recvmsg()
is a waste of resources, as thread has to immediately sleep again
because it got no payload.

More than one thread can be operating on the socket, the other one
could be waiting for the window to open up in order to do a send.  Are
you absolutely sure that we won't have a problem in that situation?

Yes, more than one thread can be operating, but the prequeue wakeups the
one blocked in tcp_recvmsg() only, because of :

wake_up_interruptible_sync_poll(sk_sleep(sk),
				POLLIN | POLLRDNORM | POLLRDBAND);


Then the ACK processing might/should wakeup the other thread blocked in
tcp_sendmsg().

So this patch will also help this (not very usual) situation, as we will
only wakeup the tcp_sendmsg() thread when ACK is processed from softirq
handler, and let the thread blocked in tcp_recvmsg() sleeping.

In fact I wonder if that does the right thing right now.

Right now it is working, because at least one thread will process the
prequeue at the exit of tcp_recvmsg()