linux-kernel - Re: [PATCH v3] irqchip/tango: Don't use incorrect irq_mask

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] [day] [month] [year] [list]
Message-ID: <de05d33b-0e7d-30b2-d9ba-e298ebc7bdd9@sigmadesigns.com>
Date:   Mon, 18 Sep 2017 10:49:56 +0200
From:   Marc Gonzalez <marc_gonzalez@...madesigns.com>
To:     Marc Zyngier <marc.zyngier@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>
CC:     Florian Fainelli <f.fainelli@...il.com>,
        Doug Berger <opendmb@...il.com>,
        Mans Rullgard <mans@...sr.com>, Mason <slash.tmp@...e.fr>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Thibaud Cornic <thibaud_cornic@...madesigns.com>
Subject: Re: [PATCH v3] irqchip/tango: Don't use incorrect irq_mask_ack
 callback

On 21/08/2017 15:25, Marc Gonzalez wrote:

> Using separate mask and ack functions (i.e. my patch)
> 
> # iperf3 -c 172.27.64.110 -t 20
> Connecting to host 172.27.64.110, port 5201
> [  4] local 172.27.64.1 port 40868 connected to 172.27.64.110 port 5201
> [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
> [  4]   0.00-1.00   sec   106 MBytes   888 Mbits/sec   18    324 KBytes
> [  4]   1.00-2.00   sec   106 MBytes   885 Mbits/sec    0    361 KBytes
> [  4]   2.00-3.00   sec   105 MBytes   883 Mbits/sec    4    279 KBytes
> [  4]   3.00-4.00   sec   106 MBytes   890 Mbits/sec    0    300 KBytes
> [  4]   4.00-5.00   sec   106 MBytes   887 Mbits/sec    0    310 KBytes
> [  4]   5.00-6.00   sec   105 MBytes   883 Mbits/sec    0    315 KBytes
> [  4]   6.00-7.00   sec   105 MBytes   885 Mbits/sec    0    321 KBytes
> [  4]   7.00-8.00   sec   105 MBytes   880 Mbits/sec    0    325 KBytes
> [  4]   8.00-9.00   sec   106 MBytes   888 Mbits/sec    0    329 KBytes
> [  4]   9.00-10.00  sec   106 MBytes   886 Mbits/sec    0    335 KBytes
> [  4]  10.00-11.00  sec   105 MBytes   885 Mbits/sec    0    351 KBytes
> [  4]  11.00-12.00  sec   106 MBytes   887 Mbits/sec    1    276 KBytes
> [  4]  12.00-13.00  sec   106 MBytes   885 Mbits/sec    0    321 KBytes
> [  4]  13.00-14.00  sec   105 MBytes   883 Mbits/sec    0    349 KBytes
> [  4]  14.00-15.00  sec   106 MBytes   890 Mbits/sec    0    366 KBytes
> [  4]  15.00-16.00  sec   106 MBytes   888 Mbits/sec    2    286 KBytes
> [  4]  16.00-17.00  sec   105 MBytes   884 Mbits/sec    0    303 KBytes
> [  4]  17.00-18.00  sec   105 MBytes   883 Mbits/sec    0    311 KBytes
> [  4]  18.00-19.00  sec   105 MBytes   880 Mbits/sec    0    315 KBytes
> [  4]  19.00-20.00  sec   106 MBytes   890 Mbits/sec    0    321 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bandwidth       Retr
> [  4]   0.00-20.00  sec  2.06 GBytes   885 Mbits/sec   25             sender
> 
> 
> Using combined mask and ack functions (i.e. Doug's patch)
> 
> # iperf3 -c 172.27.64.110 -t 20
> Connecting to host 172.27.64.110, port 5201
> [  4] local 172.27.64.1 port 41235 connected to 172.27.64.110 port 5201
> [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
> [  4]   0.00-1.00   sec   107 MBytes   897 Mbits/sec   60    324 KBytes
> [  4]   1.00-2.00   sec   107 MBytes   898 Mbits/sec    0    361 KBytes
> [  4]   2.00-3.00   sec   107 MBytes   898 Mbits/sec   39    194 KBytes
> [  4]   3.00-4.00   sec   107 MBytes   895 Mbits/sec    0    214 KBytes
> [  4]   4.00-5.00   sec   107 MBytes   901 Mbits/sec    0    223 KBytes
> [  4]   5.00-6.00   sec   108 MBytes   902 Mbits/sec    0    230 KBytes
> [  4]   6.00-7.00   sec   107 MBytes   895 Mbits/sec    0    242 KBytes
> [  4]   7.00-8.00   sec   107 MBytes   901 Mbits/sec    0    253 KBytes
> [  4]   8.00-9.00   sec   107 MBytes   899 Mbits/sec    0    264 KBytes
> [  4]   9.00-10.00  sec   108 MBytes   903 Mbits/sec    0    276 KBytes
> [  4]  10.00-11.00  sec   108 MBytes   902 Mbits/sec    0    286 KBytes
> [  4]  11.00-12.00  sec   107 MBytes   899 Mbits/sec    0    300 KBytes
> [  4]  12.00-13.00  sec   107 MBytes   898 Mbits/sec   33    247 KBytes
> [  4]  13.00-14.00  sec   107 MBytes   900 Mbits/sec    0    294 KBytes
> [  4]  14.00-15.00  sec   107 MBytes   900 Mbits/sec    0    325 KBytes
> [  4]  15.00-16.00  sec   107 MBytes   899 Mbits/sec    0    342 KBytes
> [  4]  16.00-17.00  sec   107 MBytes   898 Mbits/sec    0    351 KBytes
> [  4]  17.00-18.00  sec   108 MBytes   902 Mbits/sec    0    355 KBytes
> [  4]  18.00-19.00  sec   107 MBytes   901 Mbits/sec    0    359 KBytes
> [  4]  19.00-20.00  sec   108 MBytes   903 Mbits/sec   32    255 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bandwidth       Retr
> [  4]   0.00-20.00  sec  2.09 GBytes   900 Mbits/sec  164             sender
> 
> 
> Ergo, it seems that the performance improvement of the combined
> implementation is approximately 1.5% for a load generating ~80k
> interrupts per second.

Hello irqchip maintainers,

As mentioned upthread, there is a bug in drivers/irqchip/irq-tango.c
caused by the unexpected implementation of irq_gc_mask_disable_reg_and_ack()

That bug can be fixed either by using an appropriate irq_mask_ack callback,
or by not defining an irq_mask_ack callback at all. The first option provides
~1.5% more throughput than the second, for a typical use-case.

Whichever option you favor, can we fix this bug in current and stable branches?
(The fix was submitted two months ago.)

Regards.