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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
