From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: [PATCH 1/2 v2] ASoC: soc-cache: block based rbtree compression Date: Tue, 3 May 2011 11:47:02 +0100 Message-ID: <20110503104701.GD1762@opensource.wolfsonmicro.com> References: <1304339309-28820-1-git-send-email-dp@opensource.wolfsonmicro.com> <20110502144256.GA1656@opensource.wolfsonmicro.com> <20110502145814.GB1844@opensource.wolfsonmicro.com> <20110503094319.GA27833@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from opensource2.wolfsonmicro.com (opensource.wolfsonmicro.com [80.75.67.52]) by alsa0.perex.cz (Postfix) with ESMTP id 681981037FB for ; Tue, 3 May 2011 12:47:04 +0200 (CEST) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: Dimitris Papastamos , alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com, Liam Girdwood , Liam Girdwood List-Id: alsa-devel@alsa-project.org 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.