linux-kernel - Re: Hardware spec prevents optimal performance in device driver

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]

Date:	Sun, 10 May 2015 18:46:00 +0200
From:	Mason <slash.tmp@...e.fr>
To:	Mans Rullgard <mans@...sr.com>
CC:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	linux-serial@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Peter Hurley <peter@...leysoftware.com>
Subject: Re: Hardware spec prevents optimal performance in device driver

On 10/05/2015 12:29, Måns Rullgård wrote:

> Mason writes:
> 
>> One Thousand Gnomes wrote:
>>
>>> Mason wrote:
>>>
>>>> I'm writing a device driver for a serial-ish kind of device.
>>>> I'm interested in the TX side of the problem. (I'm working on
>>>> an ARM Cortex A9 system by the way.)
>>>>
>>>> There's a 16-byte TX FIFO. Data is queued to the FIFO by writing
>>>> {1,2,4} bytes to a TX{8,16,32} memory-mapped register.
>>>> Reading the TX_DEPTH register returns the current queue depth.
>>>>
>>>> The TX_READY IRQ is asserted when (and only when) TX_DEPTH
>>>> transitions from 1 to 0.
>>>
>>> If the last statement is correct then your performance is probably always
>>> going to suck unless there is additional invisible queueing beyond the
>>> visible FIFO.
>>
>> Do you agree with my assessment that the current semantics for
>> TX_READY lead to a race condition, unless we limit ourselves
>> to a single (atomic) write between interrupts?
> 
> No.  To get best throughput, you can simply busy-wait until TX_DEPTH
> indicates the FIFO is almost empty, then write a few words, but no more
> than you know fit in the FIFO.  Repeat until all data has been written.
> Use the IRQ only to signal completion of the entire packet.

Would you fill the FIFO with TX_READY disabled?
or with all interrupts masked?

I will show with pseudo-code where (I think) the race condition
breaks the algorithm you suggest. (When using IRQs, not busy wait.)

> If the transmit rate is low, you can save some CPU time by filling the
> FIFO, then sleeping until it should be almost empty, fill again, etc.

For one data point, the test app I have sets the tx rate to 128 kbps.
Thus, 1 ms to transmit an entire queue. CPU runs at 100-1000 MHz
depending on the mood of cpufreq.

> Whether busy-waiting or sleeping, this approach keeps the data flowing
> as fast as possible.
> 
> With the hardware you describe, there is unfortunately a trade-off
> between throughput and CPU efficiency.  You'll have to decide which is
> more important to you.

I can ask the hardware designer to change the behavior for the next
iteration of the SoC.

Regards.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/