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

[Takashi Iwai]

At Tue, 3 May 2011 10:43:20 +0100,
Mark Brown wrote:
> 
> On Mon, May 02, 2011 at 03:58:14PM +0100, Dimitris Papastamos wrote:
> > On Mon, May 02, 2011 at 04:47:41PM +0200, Takashi Iwai wrote:
> > > Dimitris Papastamos wrote:
> 
> > > Right.  But does it buy so much, in comparison with the additional
> > > complexity of the code?  That's my primary question.
> 
> > For some codecs, the register maps group together registers of similar
> > functionality.  With an optimal block size or near optimal, there will
> > be only one rbtree look up if we continually touch any of those
> > registers.  This helps primarily when we sync the register map as well
> > as during initialization.  I think the added code complexity is worth
> > it.  I could perhaps send patches incrementally to simplify this
> > further.
> 
> 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
> transmitting both the I2C device address and the register address for
> the second and subsequent registers in a block you'll usually get more
> than 100% bandwidth saving.

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?

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.


thanks,

Takashi