On 08/11/2015 12:12 PM, Eric Dumazet wrote: > On Tue, 2015-08-11 at 11:03 -0400, Jason Baron wrote: > >> >> Yes, so the test case I'm using to test against is somewhat contrived. >> In that I am simply allocating around 40,000 sockets that are idle to >> create a 'permanent' memory pressure in the background. Then, I have >> just 1 flow that sets SO_SNDBUF, which results in the: poll(), write() loop. >> >> That said, we encountered this issue initially where we had 10,000+ >> flows and whenever the system would get into memory pressure, we would >> see all the cpus spin at 100%. >> >> So the testcase I wrote, was just a simplistic version for testing. But >> I am going to try and test against the more realistic workload where >> this issue was initially observed. >> > > Note that I am still trying to understand why we need to increase socket > structure, for something which is inherently a problem of sharing memory > with an unknown (potentially big) number of sockets. >
I was trying to mirror the wakeups when SO_SNDBUF is not set, where we continue to trigger on 1/3 of the buffer being available, as the sk->sndbuf is shrunk. And I saw this value as dynamic depending on number of sockets and read/write buffer usage. So that's where I was coming from with it. Also, at least with the .config I have the tcp_sock structure didn't increase in size (although struct sock did go up by 8 and not 4). > I suggested to use a flag (one bit). > > If set, then we should fallback to tcp_wmem[0] (each socket has 4096 > bytes, so that we can avoid starvation) > > > Ok, I will test this approach. Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
