> After this patch, coverage_read() seems halfway between two designs. > My goal was to avoid holding coverage_mutex while constructing the log > message, to keep the hold time low, by copying out the totals and then > building the message with the copies. Your version retains the > copy-out for totals but extends the mutex hold time across the log > messages anyway since it needs access to new data. I'd suggest doing > the summations holding the lock but then dropping it before > constructing the log mesage. >
Yes, I'd very much like to do this. During my poking-around these two days, I know lock contention better. > I think that the units might be a little confusing. All of the units > are really per second, right? It's just that they are per second over > the last second, per second averaged over the last hour, per second > averaged over the last day. (Right?) We might want to clarify that. > I am not sure how to make it really clear in the coverage/show output, > but writing the results in some way other than "/min", "/hr" might > help, since people naturally read that as per-minute or per-hour. > No. We sample every 5 seconds. Put the sample into the minute moving averager. So when calculating the per-minute rate, we sum all the 5-second counts in the minute moving averager (12 5-sec slots = 1 minute count). The per-hour rate use the similar idea.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
