linux-kernel - Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput

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]

Message-ID: <9ddf610d-c819-14ec-42b0-0ee61c0de173@gmail.com>
Date:   Mon, 22 Aug 2016 18:44:06 -0300
From:   Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To:     Aaron Lu <aaron.lu@...el.com>
Cc:     Xin Long <lucien.xin@...il.com>,
        kernel test robot <xiaolong.ye@...el.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>, lkp@...org,
        "David S. Miller" <davem@...emloft.net>,
        LKML <linux-kernel@...r.kernel.org>,
        "Chen, Tim C" <tim.c.chen@...el.com>,
        Huang Ying <ying.huang@...el.com>
Subject: Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2%
 regression

Em 19-08-2016 04:24, Aaron Lu escreveu:
> On Fri, Aug 19, 2016 at 04:19:39AM -0300, Marcelo Ricardo Leitner wrote:
>> Hi,
>>
>> Em 19-08-2016 02:29, Aaron Lu escreveu:
>> ...
>>> It doesn't look insane and sctp_wait_for_sndbuf may actually have
>>> something to do with a larger sctp_chunk I suppose?
>>>
>>> The same perf record doesn't capture any sample for the good commit,
>>> which suggests the nerperf process doesn't sleep in sctp_wait_for_sndbuf.
>>
>> Ahhh yes! It does, and then it would mean your txbuf is too small for the
>> chunk sizes you're using (sctp tests option -m).
>>
>> What's your netperf cmdline again please?
>
> netperf -4 -t SCTP_STREAM_MANY -c -C -l 300 -- -m 10K -H 127.0.0.1
>
> Is the 10K used here a problem? If so, can you suggest a proper value
> for our netperf performance test? Thanks.

We're still working on this. Xin could reproduce it on an i3 too, but 
I'm afraid this commit just unmasked an issue in there. You're 
overloading the CPU by too much when spawning 8 parallel netperf's on a 
4-core system, seems that commit a6c2f79287 was that last rock that made 
it slip into a precipice. sctp's cwnd and rwnd management are not as 
good as tcp's and now it seems you're triggering a corner case.

I hope to have more soon.

Regards,
Marcelo