On Fri, 2015-08-07 at 18:31 +0000, 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() in a very tight loop.
> 
> Introduce sk->sk_effective_sndbuf, such that we can track the 'effective' size
> of the sndbuf, when we have a short write due to memory pressure. By using the
> sk->sk_effective_sndbuf instead of the sk->sk_sndbuf when we are under memory
> pressure, we can delay the POLLOUT until 1/3 of the buffer clears as we 
> normally
> do. There is no issue here when SO_SNDBUF is not set, since the tcp layer will
> auto tune the sk->sndbuf.
> 
> In my testing, this brought a single threaad's cpu usage down from 100% to 1%
> while maintaining the same level of throughput when under memory pressure.
> 

I am not sure we need to grow socket for something that looks like a
flag ?

Also you add a race in sk_stream_wspace() as sk_effective_sndbuf value
can change under us.

+       if (sk->sk_effective_sndbuf)
+               return sk->sk_effective_sndbuf - sk->sk_wmem_queued;
+




--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to