netdev - Re: Choppy TCP send performance

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]

Date:	Fri, 28 May 2010 15:23:12 -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 3:00 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> Le vendredi 28 mai 2010 à 14:35 -0700, Ivan Novick a écrit :
>> 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.
>
> If you use poll() or select() before issuing your write(), I believe it
> should be OK.

>From my tests select will not return until the same threshold is met
of free space: if ((atomic_read(&sk->sk_wmem_alloc) << 1) <=
sk->sk_sndbuf

I got that from systemtap output

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