linux-kernel - Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine

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: <e9c3a7c20803131706m188f9494m1cdcda8354a65f4e@mail.gmail.com>
Date:	Thu, 13 Mar 2008 17:06:19 -0700
From:	"Dan Williams" <dan.j.williams@...el.com>
To:	"Olof Johansson" <olof@...om.net>
Cc:	linuxppc-dev@...abs.org, pasemi-linux@...abs.org,
	"Nelson, Shannon" <shannon.nelson@...el.com>,
	linux-kernel@...r.kernel.org, hskinnemoen@...el.com
Subject: Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine

On Thu, Mar 13, 2008 at 4:14 PM, Olof Johansson <olof@...om.net> wrote:
>  > Dummy descriptors that do nothing but cause an interrupt is the intent.
>
>  Well, it'd be slightly more efficient to do add the interrupt attribute
>  to the last issued descriptor when it's known in advance. If the
>  underlying driver doesn't support it, adding a separate descriptor would
>  be a good fallback.
>

When it is known in advance the interrupt attribute *is* set,
otherwise the descriptor may already be in flight.

>  Anyway, this isn't likely to be a performance bottleneck. If it turns
>  out to be, I'll refactor it and submit patches.
>

Would not hurt to have another pair of eyes on this part of the code.
A rewrite of the channel switch mechanism is currently pending in
async_tx.git#upstream.

[..]
>  > >  Can't do that if it's called both from the polling as well as the IRQ
>  > >  context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
>  > >  support it will be needed.
>  > >
>  >
>  > ...do it in a tasklet.
>
>  Why? That just adds overhead and latency.
>

The original ioat_dma code used nothing heavier than spin_lock_bh.
Async_tx now assumes that local_bh_disable prevents races with any
channel's cleanup routine.  Clients can place the same kind of code in
an async_tx callback as they would in a timer callback.  The
assumption is that code using async_tx can afford its extra overhead,
which is true for raid.  This is also why you don't see async_memcpy
calls in net_dma.

--
Dan
--
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/