linux-kernel - Re: [PATCH 2/8] regmap: Add the indexed cache support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4E64A102.4060902@metafoo.de>
Date:	Mon, 05 Sep 2011 12:14:26 +0200
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Dimitris Papastamos <dp@...nsource.wolfsonmicro.com>
CC:	linux-kernel@...r.kernel.org,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Liam Girdwood <lrg@...com>,
	Graeme Gregory <gg@...mlogic.co.uk>,
	Samuel Oritz <sameo@...ux.intel.com>
Subject: Re: [PATCH 2/8] regmap: Add the indexed cache support

On 09/05/2011 11:55 AM, Dimitris Papastamos wrote:
> On Fri, Sep 02, 2011 at 10:16:06PM +0200, Lars-Peter Clausen wrote:
>> On 09/02/2011 05:46 PM, Dimitris Papastamos wrote:
>>> This is the simplest form of a cache available in regcache.  Any
>>> registers whose default value is 0 are ignored.  If any of those
>>> registers are modified in the future, they will be placed in the
>>> cache on demand.  The cache layout is essentially using the provided
>>> register defaults by the regcache core directly and does not re-map
>>> it to another representation.
>>>
>>> Signed-off-by: Dimitris Papastamos <dp@...nsource.wolfsonmicro.com>
>>
>> I wonder if we really still need indexed caches, because ...
>>
>>
>>> ---
>>>  drivers/base/regmap/Makefile           |    2 +-
>>>  drivers/base/regmap/internal.h         |    1 +
>>>  drivers/base/regmap/regcache-indexed.c |   65 ++++++++++++++++++++++++++++++++
>>>  drivers/base/regmap/regcache.c         |    3 +
>>>  include/linux/regmap.h                 |    1 +
>>>  5 files changed, 71 insertions(+), 1 deletions(-)
>>>  create mode 100644 drivers/base/regmap/regcache-indexed.c
>>>
>>> [...]
>>> +static int regcache_indexed_read(struct regmap *map, unsigned int reg,
>>> +				 unsigned int *value)
>>> +{
>>> +	int ret;
>>> +
>>> +	ret = regcache_lookup_reg(map, reg);
>>
>> ... this lookup will be slower than an rbtree lookup. And given that we use two
>> integers per register doesn't give it much size advantage either.
> 
> The indexed cache grew out of the flat cache somehow.  Do you think the
> flat cache would be more appropriate than the indexed cache?  One thing
> with the flat cache is that we need to make a flat copy of the
> cache_defaults (either partial or full).  With the indexed cache we can
> use the cache_defaults directly.
> 
> I've got a patch that changes the regcache_lookup_reg() to actually use binary
> search.  The array is kept sorted after insertions and since insertions
> are less common than readbacks it should improve things a bit.
> 

Even with a binary search the lookup will most likely be more expensive then
with an rbtree. Both have an log(n) running time, but the rbtree will most
likely have less nodes than registers, while with the indexed cache we have one
entry per register.

An option would be to switch back to a flat cache, since here the lookup is
basically free. But I don't think it is really worth the maintenance hassle,
the gains are rather marginal. Especially with my patches which add support for
merging adjacent nodes there is almost no overhead compared to the original
ASoC flat cache. You'll end up with one rbnode, so the cached rbnode is always
the one your were looking for and no rbtree lookup is necessary.

In my opinion we should work towards having rbtree as the only cache type, but
with optional lzo compression on the rbtree node blocks.

- Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/