Re: [PATCH 1/2 v2] ASoC: soc-cache: block based rbtree compression

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Tue, May 03, 2011 at 12:38:46PM +0200, Takashi Iwai wrote:
> Mark Brown wrote:

> > The other thing which Dimitris didn't mention here but which is much
> > more of a win is that for operations which work on large numbers of
> > registers like register cache restore having the registers grouped
> > together then if they're grouped together then you can normally do a
> > block I/O.  For the common case of I2C CODECs this means you can save

> So... when the low-level stuff updates the registers in a block
> manner, it'll update caches of several registers at once, too.
> If I understand correctly, the patches help for reducing the CPU usage
> because the registers looked up in such a case tend to be adjacent.
> Or am I missing other scenario?

This isn't about CPU usage, it's about I/O bandwidth which is a big
concern in situations like resume where you can be bringing the device
back up from cold.  I'd also expect better cache performance and lower
memory usage.

> Then my primary question is whether this CPU usage is really heavy.
> If such an improvement becomes really a big win, something is often
> wrong in the first stand-point; e.g. it means that RB-tree lookup
> can be too heavy, and some other method should be considered.

CPU usage isn't really that much of an issue; we need to burn an awful
lot of CPU for it to take longer than the I/O takes.