On 06/22/2016 01:34 PM, Eric Dumazet wrote:
On Wed, 2016-06-22 at 11:32 -0400, Jason Baron wrote:
From: Jason Baron <jba...@akamai.com>
When SO_SNDBUF is set and we are under tcp memory pressure, the effective
write buffer space can be much lower than what was set using SO_SNDBUF. For
example, we may have set the buffer to 100kb, but we may only be able to
write 10kb. In this scenario poll()/select()/epoll(), are going to
continuously return POLLOUT, followed by -EAGAIN from write(), and thus
result in a tight loop. Note that epoll in edge-triggered does not have
this issue since it only triggers once data has been ack'd. There is no
issue here when SO_SNDBUF is not set, since the tcp layer will auto tune
the sk->sndbuf.
Still, generating one POLLOUT event per incoming ACK will not please
epoll() users in edge-trigger mode.
Host is under global memory pressure, so we probably want to drain
socket queues _and_ reduce cpu pressure.
Strategy to insure all sockets converge to small amounts ASAP is simply
the best answer.
Letting big SO_SNDBUF offenders hog memory while their queue is big
is not going to help sockets who can not get ACK
(elephants get more ACK than mice, so they have more chance to succeed
their new allocations)
Your patch adds lot of complexity logic in tcp_sendmsg() and
tcp_sendpage().
I would prefer a simpler patch like :
Ok, fair enough. I'm going to assume that you will submit this as
a formal patch.
For 1/2, the getting the correct memory barrier, should I re-submit
that as a separate patch?
Thanks,
-Jason
