Nice to see you, May you success in your team and our open source community.
You have put forward a good proposal to queued more uevent messages by kicking uevent
processing thread in a predefined time intervals. It is also a good idea to have such intervals
configuration.
As to process several uevents for the same physical devices, I think the opinions
different between us is "FILTER" or "MERGER". Personally, I think Merger is more
accuracy, for example, we receive 4 paths addition uevent messages from the same
physical devices:
1)uevent add sdb
2)uevent add sdc
3)uevent add sdd
4)uevent add sde
We cannot just filter the 1)2)3) uevent messages but only process the 4)uevent message,
which would cause losing paths of this multipath devices.
In my opionion, we should MERGE the four uevent messages to one like:
1)uevent add sdb sdb sdd sde
And then uevent processing thread only needs to process one uevent message, and it
only produce one DM addition uevent messages(VS. now: one DM addition uevent
message and 3 DM change uevent messages) which really reduce system consumption
(for example: avoid udev to process every DM uevent messages DM kernel produced).
Regards,Tang
发件人: Martin Wilck <mwilck@xxxxxxxx>
收件人: dm-devel@xxxxxxxxxx,
日期: 2016/11/16 17:59
主题: Re: [dm-devel] Improve processing efficiency for addition and deletion of multipath devices
发件人: dm-devel-bounces@xxxxxxxxxx
Hi Tang,
On Wed, 2016-11-16 at 16:45 +0800, tang.junhui@xxxxxxxxxx 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 <mwilck@xxxxxxxx>, 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
发件人: Martin Wilck <mwilck@xxxxxxxx>
收件人: dm-devel@xxxxxxxxxx,
日期: 2016/11/16 17:59
主题: Re: [dm-devel] Improve processing efficiency for addition and deletion of multipath devices
发件人: dm-devel-bounces@xxxxxxxxxx
Hi Tang,
On Wed, 2016-11-16 at 16:45 +0800, tang.junhui@xxxxxxxxxx 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 <mwilck@xxxxxxxx>, 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
