From: Jiri Wiesner <jwiesner@suse.de>
To: Julian Anastasov <ja@ssi.bg>
Cc: Simon Horman <horms@verge.net.au>,
lvs-devel@vger.kernel.org,
yunhong-cgl jiang <xintian1976@gmail.com>,
dust.li@linux.alibaba.com
Subject: Re: [RFC PATCHv6 3/7] ipvs: use u64_stats_t for the per-cpu counters
Date: Sat, 12 Nov 2022 10:09:10 +0100 [thread overview]
Message-ID: <20221112090910.GI3484@incl> (raw)
In-Reply-To: <20221112090001.GH3484@incl>
On Sat, Nov 12, 2022 at 10:00:01AM +0100, Jiri Wiesner wrote:
> On Mon, Oct 31, 2022 at 04:56:43PM +0200, Julian Anastasov wrote:
> > Use the provided u64_stats_t type to avoid
> > load/store tearing.
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.
> >
> > Fixes: 316580b69d0a ("u64_stats: provide u64_stats_t type")
> > Signed-off-by: Julian Anastasov <ja@ssi.bg>
> > ---
> > include/net/ip_vs.h | 10 +++++-----
> > net/netfilter/ipvs/ip_vs_core.c | 30 +++++++++++++++---------------
> > net/netfilter/ipvs/ip_vs_ctl.c | 10 +++++-----
> > net/netfilter/ipvs/ip_vs_est.c | 20 ++++++++++----------
> > 4 files changed, 35 insertions(+), 35 deletions(-)
> >
> > diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> > index e5582c01a4a3..a4d44138c2a8 100644
> > --- a/include/net/ip_vs.h
> > +++ b/include/net/ip_vs.h
> > @@ -351,11 +351,11 @@ struct ip_vs_seq {
> >
> > /* counters per cpu */
> > struct ip_vs_counters {
> > - __u64 conns; /* connections scheduled */
> > - __u64 inpkts; /* incoming packets */
> > - __u64 outpkts; /* outgoing packets */
> > - __u64 inbytes; /* incoming bytes */
> > - __u64 outbytes; /* outgoing bytes */
> > + u64_stats_t conns; /* connections scheduled */
> > + u64_stats_t inpkts; /* incoming packets */
> > + u64_stats_t outpkts; /* outgoing packets */
> > + u64_stats_t inbytes; /* incoming bytes */
> > + u64_stats_t outbytes; /* outgoing bytes */
> > };
> > /* Stats per cpu */
> > struct ip_vs_cpu_stats {
>
> 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() looked like:
> 15b65: add (%rsi),%r14
> 15b68: add 0x8(%rsi),%r15
> 15b6c: add 0x10(%rsi),%r13
> 15b70: add 0x18(%rsi),%r12
> 15b74: add 0x20(%rsi),%rbp
> The u64_stats_read() calls in ip_vs_chain_estimation() turned it into:
> 159d5: mov (%rcx),%r11
> 159d8: mov 0x8(%rcx),%r10
> 159dc: mov 0x10(%rcx),%r9
> 159e0: mov 0x18(%rcx),%rdi
> 159e4: mov 0x20(%rcx),%rdx
> 159e8: add %r11,%r14
> 159eb: add %r10,%r13
> 159ee: add %r9,%r12
> 159f1: add %rdi,%rbp
> 159f4: add %rdx,%rbx
> I guess that is not a big deal because the mov should be the instruction taking the most time on account of accessing per cpu regions of other CPUs. The add will be fast.
Another concern is the number of registers needed for the summation. Previously, 5 registers were needed. Now, 10 registers are needed. This would matter mostly if the size of the stack frame of ip_vs_chain_estimation() and the number of callee-saved registers stored to the stack changed, but introducing u64_stats_read() in ip_vs_chain_estimation() did not change that.
--
Jiri Wiesner
SUSE Labs
next prev parent reply other threads:[~2022-11-12 9:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 14:56 [RFC PATCHv6 0/7] ipvs: Use kthreads for stats Julian Anastasov
2022-10-31 14:56 ` [RFC PATCHv6 1/7] ipvs: add rcu protection to stats Julian Anastasov
2022-11-12 7:51 ` Jiri Wiesner
2022-10-31 14:56 ` [RFC PATCHv6 2/7] ipvs: use common functions for stats allocation Julian Anastasov
2022-11-12 8:22 ` Jiri Wiesner
2022-10-31 14:56 ` [RFC PATCHv6 3/7] ipvs: use u64_stats_t for the per-cpu counters Julian Anastasov
2022-11-12 9:00 ` Jiri Wiesner
2022-11-12 9:09 ` Jiri Wiesner [this message]
2022-11-12 16:01 ` Julian Anastasov
2022-11-14 11:46 ` Julian Anastasov
2022-11-15 12:26 ` Jiri Wiesner
2022-11-15 16:53 ` Julian Anastasov
2022-11-16 17:37 ` Jiri Wiesner
2022-11-19 7:46 ` Jiri Wiesner
2022-10-31 14:56 ` [RFC PATCHv6 4/7] ipvs: use kthreads for stats estimation Julian Anastasov
2022-11-10 15:39 ` Jiri Wiesner
2022-11-10 20:16 ` Julian Anastasov
2022-11-11 17:21 ` Jiri Wiesner
2022-11-21 16:05 ` Jiri Wiesner
2022-10-31 14:56 ` [RFC PATCHv6 5/7] ipvs: add est_cpulist and est_nice sysctl vars Julian Anastasov
2022-11-21 16:29 ` Jiri Wiesner
2022-10-31 14:56 ` [RFC PATCHv6 6/7] ipvs: run_estimation should control the kthread tasks Julian Anastasov
2022-11-21 16:32 ` Jiri Wiesner
2022-10-31 14:56 ` [RFC PATCHv6 7/7] ipvs: debug the tick time Julian Anastasov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221112090910.GI3484@incl \
--to=jwiesner@suse.de \
--cc=dust.li@linux.alibaba.com \
--cc=horms@verge.net.au \
--cc=ja@ssi.bg \
--cc=lvs-devel@vger.kernel.org \
--cc=xintian1976@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox