On 12/16/2013 11:03 PM, Nicholas A. Bellinger wrote: > On Fri, 2013-12-13 at 15:58 -0800, Andy Grover wrote: >> Hi Nicholas, >> >> This patchset uses krefs to refcount structures shared across threads. >> LIO is full of these because configfs-based configuration actions can >> be removing an object, even while that object is being used by a SCSI >> command. >> >> Using kref to free the struct on whichever thread drops the last >> reference allows us to avoid busy-waiting in configfs removal functions. >> Next, this set removes the statically-sized tpg lun and deve arrays in >> favor of dynamically adding entries into rbtrees. This reduces memory >> consumption and allows more than 255 luns per tpg and initiator mapping. >> >> Except for some rbtree lookups, these changes are entirely in the >> configuration paths of Lio. I have tested these as extensively as I can, >> and it's ready for wider testing. >> >> Note: patch 22 converts a percpu refcount to a normal kref. I'd argue >> the benefit is really in the "refcount" part rather than the "percpu", >> so a simpler kref does the job, but we might want to discuss this some >> more. >> > > It would be helpful to breakup future patches into different series > based on: > > * Bugfixes > * New features > * Minor improvements > 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. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
