13.12.2011 20:11, Vidar Tyldum kirjoitti:
13.12.2011 08:31, Marko Ristola:
Hi
Here is a patch that went into Linus GIT this year.
It reduces the number of DMA transfer interrupts into one third.
Linus released 2.6.38.8 doesn't seem to have this patch yet
Good news, combining this patch with IRQ management fixes the problem for me.
Status:
* Stock 2.6.38.8 mantis, no IRQ management: glitches
* Stock 2.6.38.8 mantis, with IRQ management: glitches
* Patched 2.6.38.8 mantis, no IRQ management: glitches (less)
* Patched 2.6.38.8 mantis, with IRQ management: very few glitches
* Same as above, but latency_timer set to 0xff: no glitches in one hour
The patch was applied to 2.6.38.8 (in Ubuntu terms: 2.6.38-13-generic-pae).
Tests involved having VDR record on three different transponders at the same
time, which means lots of IO and all three cards active at once.
For IRQ management I tried both 'irqbalancer' and manual setting with IRQ
affinity (which is basicly what irqbalancer does).
I tried playing with the latency timer on the other scenarios, not only the
last one, but all had glitches anyways.
Not sure what to conclude with:
- Unfortunate IRQ handling on this CPU (two and two share IRQ handling)?
- Too many interrupts generated by driver (design issues)?
- Driver not handling SMP gracefully?
...or a combination?
Your patch is definately needed. Is there anything I can do to help getting
it in?
Here is a reference for Linu's master GIT tree for
the patch that went in:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=79d06d4dff733ee472e1f8933a33317a18195c0c
It will be in Linux 3.2 kernel release.
Ubuntu will take it in some day when they grab a kernel with number at least 3.2.
If you describe your problem into Ubuntu bug report system with
"There is a fix already accepted upstream. Here is a reference for the patch.",
there is a chance that you get it backported too.
I tested the patch originally very thoroughly. It improves things, but doesn't break any.
VDR wants data from the DVB card in large chunks to avoid unnecessary CPU context switching.
DVB 16KB patch is designed so, that DVB card has always some data to be delivered for VDR,
but at the same time it avoids doing unnecessary many interrupts.
Here is another patch that I wrote for my DVB HDTV network delivery glitches problem.
It might help you a bit also:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=38e009aac9e02d2c30fd9a5e979ab31433e7d578
It tries to copy DMA buffer data as fast as possible into DVB-CORE's internal 128K buffer.
Thus it prevents from Mantis DMA 64K buffer from being overrun.
It helps lots if the original dvb_dmx_swfilter(_204) is very slow, which
I saw with "perf top" tool.
Later I detected that it helps with some computers a lot, and with some other computers the patch doesn't help so much.
That patch doesn't guarantee glitch free data delivery either.
Next question is, which buffer overruns now? Mantis 64K DMA buffer? DVB-CORE's 128K buffer?
VDR reads from DVB-CORE's 128K buffer.
dvb_dmx_swfilter(_204) in media/dvb-core/dvb_demux.c is designed to drop data if DVB-CORE's 128K buffer
becomes full.
Maybe we could add into mantis_dma.c some logic:
"Mantis DMA transfer delivers data into DVB-CORE's 128K buffer in 16K chunks, avoiding the 128K buffer overrun."
"If DVB-CORE's buffer would overrun, Mantis DMA transfer sends data, if also Mantis 64K DMA buffer is
becoming full.
I suspect I2C latency problem to be a root cause for these glitches,
but there isn't a patch to test it yet. I2C latency should not be a problem
with quad core CPU: it should affect most with a single CPU computer.
"perf top" shows easilly some CPU hogs.
Regards,
Marko Ristola
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
