From: Benjamin Kidwell <benjkidwell@yahoo.com>
To: linux-kernel@vger.kernel.org
Subject: Re: Linux-next Alsa hda_intel events/0 high CPU usage, bisected
Date: Sat, 7 Jun 2008 18:56:33 -0700 (PDT) [thread overview]
Message-ID: <424883.96640.qm@web53709.mail.re2.yahoo.com> (raw)
In-Reply-To: <s5hk5h1shys.wl%tiwai@suse.de>
--- 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.
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.
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.
Ben
next prev parent reply other threads:[~2008-06-08 1:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-06 21:07 Benjamin Kidwell
2008-06-06 21:15 ` Benjamin Kidwell
2008-06-07 9:38 ` Takashi Iwai
2008-06-07 9:38 ` Takashi Iwai
2008-06-08 1:56 ` Benjamin Kidwell [this message]
2008-06-09 11:11 ` Takashi Iwai
2008-06-09 11:13 ` Takashi Iwai
2008-06-09 13:13 ` Takashi Iwai
2008-06-09 22:09 ` Benjamin Kidwell
2008-06-10 10:13 ` Takashi Iwai
2008-06-10 12:20 ` Benjamin Kidwell
2008-06-10 12:36 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=424883.96640.qm@web53709.mail.re2.yahoo.com \
--to=benjkidwell@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®