On Tue, 2013-12-17 at 09:10 -0800, Andy Grover wrote: > 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? > perf mem -t all record -a sleep 20 perf mem report --sort=mem,sym,dso,symbol_daddr,dso_daddr,tlb,locked > 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. > My understanding is that radix trees would involve less memory accesses vs. rbtrees, and less misses when cache is cold. --nab -- 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
