netdev - Re: [PATCH v2 net-next 2/2] tcp: reduce cpu usage when SO

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

Message-ID: <576AD666.7050809@akamai.com>
Date:	Wed, 22 Jun 2016 14:18:14 -0400
From:	Jason Baron <jbaron@...mai.com>
To:	Eric Dumazet <eric.dumazet@...il.com>, <davem@...emloft.net>
CC:	<netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net-next 2/2] tcp: reduce cpu usage when SO_SNDBUF is
 set



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@...mai.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