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
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
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
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
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