Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1351736 > unrolled thread

Re: Softirq priority inversion from "softirq: reduce latencies"

Started bySebastian Andrzej Siewior <bigeasy@linutronix.de>
First post2016-03-07 16:50 +0100
Last post2016-03-07 16:50 +0100
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Softirq priority inversion from "softirq: reduce latencies" Sebastian Andrzej Siewior <bigeasy@linutronix.de> - 2016-03-07 16:50 +0100

#1351736 — Re: Softirq priority inversion from "softirq: reduce latencies"

FromSebastian Andrzej Siewior <bigeasy@linutronix.de>
Date2016-03-07 16:50 +0100
SubjectRe: Softirq priority inversion from "softirq: reduce latencies"
Message-ID<ra5zZ-4I3-37@gated-at.bofh.it>
On 02/27/2016 07:19 PM, Peter Hurley wrote:
> Hi Eric,

Hi Peter,

> Because both the uart driver (omap8250) and the dmaengine driver
> (edma) were (relatively) new, we assumed there was some race between
> starting a new rx DMA and processing the previous one.

Now after digesting the whole thread. I complained about this a long
while ago. After you start RX-DMA the DMA-engine is not programmed
immediately but deferred into softirq/tasklet. This is not the case for
continuous DMA transfer - those are programmed right away.

I don't remember that I found a reason why this simple programming has
to be deferred and can't happen immediately like it is the case for the
continuous DMA transfers. So I skipped that. RX-DMA in UART was working
well but for some reason omap's MMC-card driver refused to work.

Sebastian

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web