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: <877fcg25c4.fsf@belgarion.home>
Date:	Wed, 20 Jul 2016 08:26:03 +0200
From:	Robert Jarzmik <robert.jarzmik@...e.fr>
To:	Peter Ujfalusi <peter.ujfalusi@...com>
Cc:	Russell King - ARM Linux <linux@...linux.org.uk>,
	vinod.koul@...el.com, linux-kernel@...r.kernel.org,
	tony@...mide.com, dmaengine@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/7] dmaengine: omap-dma: Complete the cookie first on transfer completion

Peter Ujfalusi <peter.ujfalusi@...com> writes:

> On 07/18/16 13:34, Russell King - ARM Linux wrote:
>> On Thu, Jul 14, 2016 at 03:42:37PM +0300, Peter Ujfalusi wrote:
>>> Before looking for the next descriptor to start, complete the just finished
>>> cookie.
>> 
>> This change will reduce performance as we no longer have an overlap
>> between the next request starting to be dealt with in the hardware
>> vs the previous request being completed.
>
> vchan_cookie_complete() will only mark the cookie completed, adds the vd to
> the desc_completed list (it was deleted from desc_issued list when it was
> started by omap_dma_start_desc) and schedule the tasklet to deal with the real
> completion later.
> Marking the just finished descriptor/cookie done first then looking for
> possible descriptors in the queue to start feels like a better sequence.
>
> After a quick grep in the kernel source: only omap-dma.c was starting the next
> transfer before marking the current completed descriptor/cookie done.

Euh actually I think it's done in other drivers as well :
 - Documentation/dmaengine/pxa_dma.txt (chapter "Transfers hot-chaining)
 - drivers/dma/pxa_dma.c
   => look for pxad_try_hotchain() and it's impact on pxad_chan_handler() which
   will mark the completion while the next transfer is already pumped by the
   hardware.

Speaking of which, from a purely design point of view, as long as you think
beforehand what is your sequence, ie. what is the sequence of your link
chaining, completion handling, etc ..., both marking before or after next tx
start should be fine IMHO.

So in your quest for the "better sequence" the pxa driver's one might give you
some perspective :)

Cheers.

-- 
Robert

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ