alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lrg@ti.com>
Subject: Re: [PATCH 1/4] Revert "ASoC: tlv320dac33: Use core to set the msbits constraint"
Date: Thu, 19 Jan 2012 19:07:01 +0000	[thread overview]
Message-ID: <20120119190701.GN3178@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4F1861E6.1000700@ti.com>

On Thu, Jan 19, 2012 at 07:33:10PM +0100, Peter Ujfalusi wrote:

> It might not bother you that we are wasting CPU cycles for nothing, but
> it annoys me.
> This is the reason we need to update the CPUs every 2 years.

> Please take this series. I'm not going to allow that the TI drivers will
> waste CPU cycles (for nothing).

Please take a step back (I know I'm rather annoyed and am trying to do
so myself), none of this is getting us anywhere.

We've got real CPU consumption problems in ASoC - the DAPM algorithm is
the biggest one, even with the work I did recently to mitigate against
it it's still got the ability to explode dramatically to the point where
it's user visible as the worst case is well over O(n^2).  There's plenty
of low hanging fruit that it'd be much better to spend time on here - as
a quick example every time we start or stop a stream we do a linear
search of all DAPM widgets looking for those that might be affected
based on a string match in order to kick DAPM for them.  That's O(n) in
the number of widgets in the card plus the strcmp() costs.

We'll all get *much* more benefit from working on improvements of things
like that (and on the memory consumption which isn't great either and
probably manages to burn measurable CPU cycles due to cache misses) than
we ever will from anything we do with this code.

  reply	other threads:[~2012-01-19 19:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-19 18:24 [PATCH 0/4] ASoC: Do not use core to handle msbits constraint for TI drivers Peter Ujfalusi
2012-01-19 18:24 ` [PATCH 1/4] Revert "ASoC: tlv320dac33: Use core to set the msbits constraint" Peter Ujfalusi
2012-01-19 18:26   ` Mark Brown
2012-01-19 18:33     ` Peter Ujfalusi
2012-01-19 19:07       ` Mark Brown [this message]
2012-01-21 14:05         ` Peter Ujfalusi
2012-01-21 15:20           ` Mark Brown
2012-01-19 18:24 ` [PATCH 2/4] Revert "ASoC: twl4030: " Peter Ujfalusi
2012-01-19 18:24 ` [PATCH 3/4] Revert "ASoC: omap-dmic: " Peter Ujfalusi
2012-01-19 18:24 ` [PATCH 4/4] ASoC: omap-mcpdm: Do not use core to set msbit constraint Peter Ujfalusi

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=20120119190701.GN3178@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@ti.com \
    --cc=peter.ujfalusi@ti.com \
    /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;
as well as URLs for NNTP newsgroup(s).