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