Hi Tang, On Wed, 2016-11-16 at 16:45 +0800, tang.jun...@zte.com.cn wrote:
> I think we can merger most of uevent messages and reduce most of > unnecessary DM change > uevent messages during creation/deletion of multipath devices by this > way. > The method you mentioned I think that it is a little complex, and it > not reduce the DM > addition/change/deletion uevent messages which consumed system high > resource. Let me quickly introduce myself, I'm a new member of Hannes' team at SUSE and new on this ML. Apart from Hannes' proposal for more fine-grained locking, I can see the following options: a) instead of kicking the uevent processing thread whenever anything is queued, kick it in predefined time intervals (1 second, say). The uevent processor would then accumulate all changes received since it had been kicked last, and apply DM changes only when necessary. This may need to be a config option because it could obviously lead to delayed device setup in some configurations. b) the logic of a) could be improved by the uevent listener detecting "event storms" and waiting for them to end before kicking the processing thread. The details of the heuristics for "storms" would need to be worked out, of course. c) sometimes several uevents for the same physical path occur in quick succession. Normally it should be sufficient to filter these such that only the last event is processed. Regards, Martin -- Dr. Martin Wilck <mwi...@suse.com>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
