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

[Takashi Iwai]

At Tue, 3 May 2011 11:47:02 +0100,
Mark Brown wrote:
> 
> 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.

Hm, but how do these patches achieve it?  I see no change in the I/O
access side.

> I'd also expect better cache performance and lower memory usage.

Pretty depends on the register mapping, I suppose.

> > 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.

Yes, that's why I've been asking it...


Takashi