[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTilZxoSEGOhmWdk2RbIGMmCMi2yNJm9rUwIzDIoL@mail.gmail.com>
Date: Fri, 28 May 2010 14:35:10 -0700
From: Ivan Novick <novickivan@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: netdev@...r.kernel.org, Tim Heath <theath@...enplum.com>
Subject: Re: Choppy TCP send performance
On Fri, May 28, 2010 at 2:16 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le vendredi 28 mai 2010 à 13:38 -0700, Ivan Novick a écrit :
>> sk_stream_wait_memory seems to be called when the send buffer is full
>> and the next send call does not complete until the send buffer
>> utilization goes down from 4,194,304 bytes to 2,814,968 bytes.
>>
>> This implies that the send that blocks on a full send buffer will not
>> complete until there is 1 meg of free space in the send buffer even
>> though the send could be accepted into the OS with only 128KB of free
>> space.
>>
>
> static void sock_def_write_space(struct sock *sk)
> {
> ...
> if ((atomic_read(&sk->sk_wmem_alloc) << 1) <= sk->sk_sndbuf) {
> ...
>
>
> Quick answer is : No, this is not tunable ( independantly than SNDBUF )
>
> SO_SNDLOWAT is not implemented on linux, yet (its value is : 1).
>
>
> Why would you want to wakeup your thread more than necessary ?
Cool. This helps me understand what is happening.
My user thread wants to wake up as soon as the OS can accept my data
so that it can continue doing work and interact with other components
in the system. This is an application issue, i can work around it now
that i have a better understanding of what the kernel is doing.
Cheers,
Ivan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists