Hello, OK. I relied on the mentioned commit to explain the problem as other similar patches do. chain_max is probably 37 here and 1.7% is low enough (below 1/37) not to be accounted in chain_max. Bad
All right. It is counter-intuitive but I guess those compiles have their reasons. I think it would not hurt to expand the description of the patch with the explanation above. I have tested the change
Hello, Some compilers for 64-bit can use two 32-bit loads (load tearing) while we require atomic 64-bit read in case reader is interrupted by updater. That is why READ_ONCE is used now. I don't know
I think only 32-bit machines have a problem storing a 64-bit counter atomically. u64_stats_fetch_begin() and u64_stats_fetch_retry() should take care of that. Another concern is the number of registe
Converting the per cpu stat to u64_stats_t means that the compiler cannot optimize the memory access and addition on x86_64. Previously, the summation of per cpu counters in ip_vs_chain_estimation()
Use the provided u64_stats_t type to avoid load/store tearing. Fixes: 316580b69d0a ("u64_stats: provide u64_stats_t type") Signed-off-by: Julian Anastasov <ja@xxxxxx> -- include/net/ip_vs.h | 10 ++++