On 08/11/2015 01:59 PM, Jason Baron wrote:
>
>
> 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 a
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 t
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 S
On 08/11/2015 10:49 AM, Eric Dumazet wrote:
> On Tue, 2015-08-11 at 14:38 +, Jason Baron wrote:
>> From: Jason Baron
>
>> In my testing, this brought a single threaad's cpu usage down from 100% to
>> ~1%
>> while maintaining the same level of throughput.
>>
>
> Hi Jason. Could you give mo
On Tue, 2015-08-11 at 14:38 +, Jason Baron wrote:
> From: Jason Baron
> In my testing, this brought a single threaad's cpu usage down from 100% to ~1%
> while maintaining the same level of throughput.
>
Hi Jason. Could you give more details on this test ?
How many flows are competing ?
From: Jason Baron
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(), ar
