Re: [dm-devel] [PATCH 08/12] libmultipath: wait one seconds for more uevents in uevent_listen() in uevents burst situations

Hello Ben, I know the issue of socket's buffer fills up, but I think uevent_can_discard() totally process in memory, it is light-weight and low cpu consumption, and it reduce the iteration count in merging, the test result is also good in massive multipath devices scene. But if you still

Re: [dm-devel] [PATCH 08/12] libmultipath: wait one seconds for more uevents in uevent_listen() in uevents burst situations

On Tue, Dec 27, 2016 at 04:03:25PM +0800, tang.jun...@zte.com.cn wrote: > From: tang.junhui > > The more uevents are merged, the higher efficiency program will performs. > So, do not process uevents after receiving immediately in uevents burst > situations, but continue

[dm-devel] [PATCH 08/12] libmultipath: wait one seconds for more uevents in uevent_listen() in uevents burst situations

From: tang.junhui The more uevents are merged, the higher efficiency program will performs. So, do not process uevents after receiving immediately in uevents burst situations, but continue wait one seconds for more uevents except that too much uevents (2048) have already

Re: [dm-devel] [PATCH 08/12] libmultipath: wait one seconds for more uevents in uevent_listen() in uevents burst situations

On Tue, 2016-12-27 at 16:03 +0800, tang.jun...@zte.com.cn wrote: > From: tang.junhui > > The more uevents are merged, the higher efficiency program will > performs. > So, do not process uevents after receiving immediately in uevents > burst > situations, but continue wait

[dm-devel] [PATCH 08/12] libmultipath: wait one seconds for more uevents in uevent_listen() in uevents burst situations

From: tang.junhui The more uevents are merged, the higher efficiency program will performs. So, do not process uevents after receiving immediately in uevents burst situations, but continue wait 1 seconds for more uevents except that too much uevents (2048) have already