Ilya Maximets <[email protected]> writes: > During namespace initialization the masks rebalancing work is > scheduled and automatically re-scheduled every 4 seconds afterwards. > This is happening in every namespace. On a large kubernetes node with > 500 pods, i.e., 500+ namespaces, this creates a decent amount of > unnecessary churn scheduling 500 jobs every 4 seconds that take the > mutex, check that there are no datapaths in their namespace, release > the mutex, re-schedule themselves and exit. These 500 unnecessary > mutex locks may hold off operations in a single namespace that > actually has a datapath configured and has real user requests to > handle under this lock. They can also add delay to removal of other > namespaces as ovs_exit_net() needs to take that lock as well and > synchronously waits for the work to be cancelled. > > Let's only fire the job when the first datapath is actually created > and not re-arm it if there are no more datapaths configured in the > namespace. > > Another approach would be to make ovs_mutex per-namespace, but it's > a much larger change that should be handled separately, and the > unnecessary work scheduling feels like a waste regardless. > > It's safe to check and re-arm outside of the mutex as DP_CMD_NEW > handler will re-arm if the new datapath appears. The scheduling > attempt also doesn't change the work or delay if it is already queued, > so it's also safe to call multiple times. > > Skipping the re-arming is more elegant than canceling on removal of > the last datapath as it allows us to not think about potential race > conditions at a negligible cost of potentially one extra re-scheduling. > > msecs_to_jiffies() moved to the macro to save on line length. > > Signed-off-by: Ilya Maximets <[email protected]> > ---
Reviewed-by: Aaron Conole <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
