linux-kernel - Re: [PATCH v1 0/3] reduce tty latency

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: <20190110135153.GA9966@kroah.com>
Date:   Thu, 10 Jan 2019 14:51:53 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     Jiri Slaby <jslaby@...e.com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/3] reduce tty latency

On Thu, Jan 10, 2019 at 11:12:29AM +0100, Oleksij Rempel wrote:
> This patch set is reducing latency on tty path.
> For testing I used hackbench running on all cores of 4 core system and
> high prioritized application sending and receiving packets over tty interface
> with loop-back adapter.

Odd, all of these ended up in my spam folder, you might want to check
your server email settings...

> Results without this patches:
>         latency histogram:
>             0 ... <     250 usec : 1933104 transmissions
>           250 ... <     500 usec : 21339 transmissions
>           500 ... <     750 usec : 8952 transmissions
>           750 ... <    1000 usec : 6226 transmissions
>          1000 ... <    1500 usec : 7688 transmissions
>          1500 ... <    2000 usec : 5236 transmissions
>          2000 ... <    5000 usec : 11724 transmissions
>          5000 ... <   10000 usec : 3588 transmissions
>         10000 ... <   50000 usec : 2123 transmissions
>         50000 ... < 1000000 usec : 20 transmissions
>                  >= 1000000 usec : 0 transmissions
> 
> Test results after this patches:
>         min latency: 0 sec : 75 usec
>         max latency: 0 sec : 125 usec
>         average latency: 81 usec
>         latency measure cycles overall: 79000000
>         latency histogram:
>             0 ... <     250 usec : 79000000 transmissions
>           250 ... <     500 usec : 0 transmissions
>           500 ... <     750 usec : 0 transmissions
>           750 ... <    1000 usec : 0 transmissions
>          1000 ... <    1500 usec : 0 transmissions
>          1500 ... <    2000 usec : 0 transmissions
>          2000 ... <    5000 usec : 0 transmissions
>          5000 ... <   10000 usec : 0 transmissions
>         10000 ... <   50000 usec : 0 transmissions
>         50000 ... < 1000000 usec : 0 transmissions
>                  >= 1000000 usec : 0 transmissions
>         average no. of read calls to assemble the packet: 1 

Like Linus said, who runs a real-world system that cares about this
latency measurement?

Yes, it might be fun for odd benchmarks to show the value of one RT
patchset/OS vs. another one, but this change can cause real issues in
real systems that do real, non-serial-loopback work.

thanks,

greg k-h