Re: Improve processing efficiency for addition and deletion of multipath devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux