Re: [PATCH v2 net-next 2/2] tcp: reduce cpu usage when SO_SNDBUF is set

[Jason Baron <jbaron@akamai.com>]

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 <jbaron@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