Hi Junhui, On 11/28/2016 03:19 AM, tang.junhui@xxxxxxxxxx wrote: > Hello Christophe, Ben, Hannes, Martin, Bart, > I am a member of host-side software development team of ZXUSP storage > project in ZTE Corporation. Facing the market demand, our team decides to write > code to promote multipath efficiency next month. The whole idea is in the mail > below. We hope to participate in and make progress with the open source community, > so any suggestion and comment would be welcome. > Thank you for looking into it. This is one area which definitely needs improvement, so your contribution would be most welcome. > > ------------------------------------------------------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------------------------------------------------------ > > 1. Problem > In these scenarios, multipath processing efficiency is low: > 1) Many paths exist in each multipath device, > 2) Devices addition or deletion during iSCSI login/logout or FC link > up/down. > > 2. Reasons > Multipath process uevents one by one, and each one also produce a new dm > addition change or deletionuevent to increased system resource consumption, > actually most of these uevents have no sense at all. > [ .. ] > In list_merger_uevents(&uevq_tmp), each node is traversed from the > latest to the oldest, > and the older node with the same WWID and uevent type(e.g. add) would be > moved to > the merger_node list of the later node. If a deletion uevent node > occurred, other older > uevent nodes about this device would be filtered(Thanks to Martin’s idea). > > After above processing, attention must be paid to that the parameter > “struct uevent * uev” is not a single uevent any more in and after > uev_trigger(), code > need to be modified to process batch uevents in uev_add_path() and so on. > To handle this properly you need to modify uev_add_path(); basically you need to treat 'uev_add_path()' and 'ev_add_path()' as two _distinct_ events, where the former processes uevents and add the path to an internal list (->pathvec would be ideally suited here). 'ev_add_path()' then would need to be called once all uevents are processed, and would be processing all elements in ->pathvec, creating the resulting multipath map in one go. Actually not a bad idea. Tricky bit would be to figure out _when_ to stop uevent processing and calling 'ev_add_path'. I guess we'd need to make 'ev_add_path' running in a separate thread; that way we'd be putting pressure off the uevent processing thread and the whole thing should be running far smoother. And looking at it closer, when you move 'ev_add_path' into a separate thread, and separating out 'uev_add_path' you _already_ have your event merging implemented. With much less effort then trying to merge things at the uevent level. I'd be willing to look into it; please keep me informed about any progress here. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
