Hello, On Fri, 4 Dec 2020, dust.li wrote: > > On 12/3/20 4:48 PM, Julian Anastasov wrote: > > > > - work will use spin_lock_bh(&s->lock) to protect the > > entries, we do not want delays between /proc readers and > > the work if using mutex. But _bh locks stop timers and > > networking for short time :( Not sure yet if just spin_lock > > is safe for both /proc and estimator's work. Here stopping BH is may be not so fatal if some CPUs are used for networking and others for workqueues. > Thanks for sharing your thoughts ! > > > I think it's a good idea to split the est_list into different > > slots, I believe it will dramatically reduce the delay brought > > by estimation. 268ms/64 => 4ms average. As the estimation with single work does not utilize many CPUs simultaneously, this can be a problem for 300000-400000 services but this looks crazy. > My only concern is the cost of the estimation when the number of > > services is large. Splitting the est_list won't reduce the real > > work to do. > > In our case, each estimation cost at most 268ms/2000ms, which is > > about 13% of one CPU hyper-thread, and this should be a common case > > in a large K8S cluster with lots of services. > > Since the estimation is not needed in our environment at all, it's > > just a waste of CPU resource. Have you ever consider add a switch to > > let the user turn the estimator off ? No problem to add sysctl var for this, we usually add function to check which can be used in ip_vs_in_stats, ip_vs_out_stats, ip_vs_conn_stats. If switch can be changed at any time, what should we do? Add/Del est entries as normally but do not start the delayed work if flag disables stats. When flag is enabled counters will increase and we will start delayed work. Regards -- Julian Anastasov <ja@xxxxxx>
