On 12/17/2013 02:53 AM, Hannes Reinecke wrote:
But the LUN addressing improvements is interesting.
What I found during development of the 64bit LUN patchset is
that the target core stuff has a very rudimentary LUN handling:
- 256 LUNs only
- LUNs are kept in a static array
- Identity mapping between LUN numbers and array indices.
What I _really_ would like to have is to do away with the
LUN array, and introduce a dynamic LUN mapping.
This will allow us to easily implement different LUN enumeration
methods (Think of hierarchical LUNs ...).
Also the assumption that a static array is always faster for
lookup than a linked list is wrong.
A static array is faster if the entire array fits into the processor
cache. If it doesn't we basically have an immediate
cache miss _for every array access_.
Then linked lists etc really are faster.
So do not take things at face value; only real measurements
count here.
Yeah, seems true. So do either of you have any tips for how best to do
measurements?
BTW I was looking a little more and am now inclined to think a radix
tree is more suitable than rbtree. It seems ideally suited for our case:
want to lookup by an index (i.e. LUN) that is usually a small integer,
very fast lookups, yet also can grow and still be space-efficient.
Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
