Re: Linux-next Alsa hda_intel events/0 high CPU usage, bisected

At Sat, 7 Jun 2008 18:56:33 -0700 (PDT),
Benjamin Kidwell wrote:

--- Takashi Iwai <> wrote:

The problem is that your hardware reports the wrong DMA position.
I didn't expect that this delay is so much, (IOW, the hardware is so
buggy). Maybe it should be put into its own workq.

I've been getting my process timing information from ps, top, and htop, which
I know can be unreliable in some ways (I've been using a tickless (NO_HZ=y)
kernel). I recompiled the g8a4bd4d kernel with that option off and a few more
changes to make my settings more conservative, and rechecked events/0. It
still reports at a consistent 2.5%, (down from about 4.3% with previous kernel
options) and after a short period of use (uptime 30 minutes) events/0 has had
0:48 of time. In comparison, Xorg and Firefox (usually the biggest users)
report 1:12 and 0:44 in the same timeframe.

So if I understand the purpose of the code, that means that my system has
generated 48 seconds worth of timing mistakes in audio playback relative to 25
minutes or so of audio stream, so that suggests the timing error of the
hardware is about 3%! That seems like huge latency for hardware so I see why
you wouldn't expect that.

Could you check the patch below in addition? It's against my latest
git tree and should be applicable as is to linux-next (since it merges
from my tree), too.

This will show some latency time in the kernel messages. If the
average latency is about 20 or 30us, this is almost in the expected
range. Occasional high latencies should be the result of
cond_resched(), so it can be ignored.

I should also say that close listening has convinced me that my audio
performance has been IMPROVED by the patch - IOW, the code is working well at
improving the audio stream, even though its using a fair amount of CPU time to
do it. With the new code, I seem to hear less random clicks, interruptions, or
static that I had previously blamed on the source of the audio. I don't know
how to test the output to the speakers relative to the input source
quantitatively, though.

First we need to gather some hardware information to sort out the
issue. If the latency is almost constant, we may add some another
trick, e.g. setting different IRQ-trigger pointers. I'll prepare
another patch.


Given that the worst-case-scenario for compensating for buggy hardware is
worse than expected, what is the best behavior for the driver given hardware
like mine? I don't know if a high CPU time for the events/0 process is
actually a problem, I'm just not used to seeing a -5 niceness process so
active under top. Let me know if you'd like any more info on my hardware or
setup, or if there are any additional kernel config options that might affect
my DMA reporting errors. I'm trying to be a useful linux-next tester, so any
advice is appreciated.

The loop has cond_resched() and thus it won't give a significant
system latency (and thus niceness wouldn't be much important here).
But, of course, such a loop takes some CPU time, and it'd be better to
avoid.


thanks,

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

Relevant Pages

  • Re: Attempted summary of "RT patch acceptance" thread
    ... > AFAICT even RTAI would be affected, because X lets userspace drivers ... > talk directly to the hardware including wedging the PCI bus. ... I made the usb example exactly to show how latency bugs can be ... (this usb thing breaks kernel latency for years and yet nobody fixed it ...
    (Linux-Kernel)
  • Re: Attempted summary of "RT patch acceptance" thread
    ... >> talk directly to the hardware including wedging the PCI bus. ... > (this usb thing breaks kernel latency for years and yet nobody fixed it ... hyperbole where drivers screw with latency is finite. ...
    (Linux-Kernel)
  • kernel BUG at mm/slab.c:610
    ... I'm experimenting this kernel panic on 3 different ... I don't think this is related to buggy hardware ... Filesystem "hda1": Disabling barriers, not supported by the ... # ACPI Support ...
    (Linux-Kernel)
  • Re: [PATCH tip/core/rcu 0/21] v6 add lockdep-based diagnostics to rcu_dereference()
    ... RCU infrastructure in place, the next eight use this infrastructure in the ... some of the remaining will be triggered only by hardware I don't have ... access to and kernel features I am unfamiliar with. ... # AX.25 network device drivers ...
    (Linux-Kernel)
  • Re: PROBLEM: cannot get stable system since 2.6.28 kernel (amd64)
    ... Philippe> well, I don't really believe in hardware problem for two ... Philippe> older kernel, everything works like a charm, every time I ... Philippe> I haven't any "overclocking" settings, and every hardware ... # Device Drivers ...
    (Linux-Kernel)