While creating 1000 containers, perf is showing lot of time spent in
snmp_fold_field on a large cpu system.
The current patch tries to improve by reordering the statistics gathering.
Please note that similar overhead was also reported while creating
veth pairs https://lkml.org/lkml/2013/3/19/556
Changes in V2:
- Allocate the stat calculation buffer in stack. (Eric)
Setup:
160 cpu (20 core) baremetal powerpc system with 1TB memory
1000 docker containers was created with command
docker run -itd ubuntu:15.04 /bin/bash in loop
observation:
Docker container creation linearly increased from around 1.6 sec to 7.5 sec
(at 1000 containers) perf data showed, creating veth interfaces resulting in
the below code path was taking more time.
rtnl_fill_ifinfo
-> inet6_fill_link_af
-> inet6_fill_ifla6_attrs
-> snmp_fold_field
proposed idea:
currently __snmp6_fill_stats64 calls snmp_fold_field that walks
through per cpu data to of an item (iteratively for around 90 items).
The patch tries to aggregate the statistics by going through
all the items of each cpu sequentially which is reducing cache
misses.
Performance of docker creation improved by around more than 2x
after the patch.
before the patch:
================
time docker run -itd ubuntu:15.04 /bin/bash
3f45ba571a42e925c4ec4aaee0e48d7610a9ed82a4c931f83324d41822cf6617
real 0m6.836s
user 0m0.095s
sys 0m0.011s
perf record -a docker run -itd ubuntu:15.04 /bin/bash
=======================================================
# Samples: 32K of event 'cycles'
# Event count (approx.): 24688700190
# Overhead Command Shared Object Symbol
# ........ ............... ...................... ........................
50.73% docker [kernel.kallsyms] [k] snmp_fold_field
9.07% swapper [kernel.kallsyms] [k] snooze_loop
3.49% docker [kernel.kallsyms] [k] veth_stats_one
2.85% swapper [kernel.kallsyms] [k] _raw_spin_lock
1.37% docker docker [.] backtrace_qsort
1.31% docker docker [.] strings.FieldsFunc
cache-misses: 2.7%
after the patch:
=============
time docker run -itd ubuntu:15.04 /bin/bash
4e0619421332990bdea413fe455ab187607ed63d33d5c37aa5291bc2f5b35857
real 0m3.357s
user 0m0.092s
sys 0m0.010s
perf record -a docker run -itd ubuntu:15.04 /bin/bash
=======================================================
# Samples: 15K of event 'cycles'
# Event count (approx.): 11471830714
# Overhead Command Shared Object Symbol
# ........ ............... .................... .........................
10.56% swapper [kernel.kallsyms] [k] snooze_loop
8.72% docker [kernel.kallsyms] [k] snmp_get_cpu_field
7.59% docker [kernel.kallsyms] [k] veth_stats_one
3.65% swapper [kernel.kallsyms] [k] _raw_spin_lock
3.06% docker docker [.] strings.FieldsFunc
2.96% docker docker [.] backtrace_qsort
cache-misses: 1.38 %
Please let me know if you have suggestions/comments.
Thanks Eric and David for comments on V1.
Raghavendra K T (2):
net: Introduce helper functions to get the per cpu data
net: Optimize snmp stat aggregation by walking all the percpu data at
once
include/net/ip.h | 10 ++++++++++
net/ipv4/af_inet.c | 41 +++++++++++++++++++++++++++--------------
net/ipv6/addrconf.c | 18 +++++++++++++-----
3 files changed, 50 insertions(+), 19 deletions(-)
--
1.7.11.7
Signed-off-by: Raghavendra K T <[email protected]>
---
include/net/ip.h | 10 ++++++++++
net/ipv4/af_inet.c | 41 +++++++++++++++++++++++++++--------------
2 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index d5fe9f2..93bf12e 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -202,10 +202,20 @@ void ip_send_unicast_reply(struct sock *sk, struct sk_buff *skb,
#define NET_ADD_STATS_BH(net, field, adnd) SNMP_ADD_STATS_BH((net)->mib.net_statistics, field, adnd)
#define NET_ADD_STATS_USER(net, field, adnd) SNMP_ADD_STATS_USER((net)->mib.net_statistics, field, adnd)
+u64 snmp_get_cpu_field(void __percpu *mib, int cpu, int offct);
unsigned long snmp_fold_field(void __percpu *mib, int offt);
#if BITS_PER_LONG==32
+u64 snmp_get_cpu_field64(void __percpu *mib, int cpu, int offct,
+ size_t syncp_offset);
u64 snmp_fold_field64(void __percpu *mib, int offt, size_t sync_off);
#else
+static inline u64 snmp_get_cpu_field64(void __percpu *mib, int cpu, int offct,
+ size_t syncp_offset)
+{
+ return snmp_get_cpu_field(mib, cpu, offct);
+
+}
+
static inline u64 snmp_fold_field64(void __percpu *mib, int offt, size_t syncp_off)
{
return snmp_fold_field(mib, offt);
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 9532ee8..302e36b 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1448,38 +1448,51 @@ int inet_ctl_sock_create(struct sock **sk, unsigned short family,
}
EXPORT_SYMBOL_GPL(inet_ctl_sock_create);
+u64 snmp_get_cpu_field(void __percpu *mib, int cpu, int offt)
+{
+ return *(((unsigned long *)per_cpu_ptr(mib, cpu)) + offt);
+}
+EXPORT_SYMBOL_GPL(snmp_get_cpu_field);
+
unsigned long snmp_fold_field(void __percpu *mib, int offt)
{
unsigned long res = 0;
int i;
for_each_possible_cpu(i)
- res += *(((unsigned long *) per_cpu_ptr(mib, i)) + offt);
+ res += snmp_get_cpu_field(mib, i, offt);
return res;
}
EXPORT_SYMBOL_GPL(snmp_fold_field);
#if BITS_PER_LONG==32
+u64 snmp_get_cpu_field64(void __percpu *mib, int cpu, int offct,
+ size_t syncp_offset)
+{
+ void *bhptr;
+ struct u64_stats_sync *syncp;
+ u64 v;
+ unsigned int start;
+
+ bhptr = per_cpu_ptr(mib, cpu);
+ syncp = (struct u64_stats_sync *)(bhptr + syncp_offset);
+ do {
+ start = u64_stats_fetch_begin_irq(syncp);
+ v = *(((u64 *)bhptr) + offt);
+ } while (u64_stats_fetch_retry_irq(syncp, start));
+
+ return v;
+}
+EXPORT_SYMBOL_GPL(snmp_get_cpu_field64);
+
u64 snmp_fold_field64(void __percpu *mib, int offt, size_t syncp_offset)
{
u64 res = 0;
int cpu;
for_each_possible_cpu(cpu) {
- void *bhptr;
- struct u64_stats_sync *syncp;
- u64 v;
- unsigned int start;
-
- bhptr = per_cpu_ptr(mib, cpu);
- syncp = (struct u64_stats_sync *)(bhptr + syncp_offset);
- do {
- start = u64_stats_fetch_begin_irq(syncp);
- v = *(((u64 *) bhptr) + offt);
- } while (u64_stats_fetch_retry_irq(syncp, start));
-
- res += v;
+ res += snmp_get_cpu_field(mib, cpu, offct, syncp_offset);
}
return res;
}
--
1.7.11.7
Docker container creation linearly increased from around 1.6 sec to 7.5 sec
(at 1000 containers) and perf data showed 50% ovehead in snmp_fold_field.
reason: currently __snmp6_fill_stats64 calls snmp_fold_field that walks
through per cpu data of an item (iteratively for around 90 items).
idea: This patch tries to aggregate the statistics by going through
all the items of each cpu sequentially which is reducing cache
misses.
Docker creation got faster by more than 2x after the patch.
Result:
Before After
Docker creation time 6.836s 3.357s
cache miss 2.7% 1.38%
perf before:
50.73% docker [kernel.kallsyms] [k] snmp_fold_field
9.07% swapper [kernel.kallsyms] [k] snooze_loop
3.49% docker [kernel.kallsyms] [k] veth_stats_one
2.85% swapper [kernel.kallsyms] [k] _raw_spin_lock
perf after:
10.56% swapper [kernel.kallsyms] [k] snooze_loop
8.72% docker [kernel.kallsyms] [k] snmp_get_cpu_field
7.59% docker [kernel.kallsyms] [k] veth_stats_one
3.65% swapper [kernel.kallsyms] [k] _raw_spin_lock
Signed-off-by: Raghavendra K T <[email protected]>
---
net/ipv6/addrconf.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
Change in V2:
- Allocate stat calculation buffer in stack (Eric)
Thanks David and Eric for coments on V1 and as both of them pointed,
unfortunately we cannot get rid of buffer for calculation without avoiding
unaligned op.
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 21c2c81..0f6c7a5 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4624,16 +4624,22 @@ static inline void __snmp6_fill_statsdev(u64 *stats, atomic_long_t *mib,
}
static inline void __snmp6_fill_stats64(u64 *stats, void __percpu *mib,
- int items, int bytes, size_t syncpoff)
+ int items, int bytes, size_t syncpoff,
+ u64 *buff)
{
- int i;
+ int i, c;
int pad = bytes - sizeof(u64) * items;
BUG_ON(pad < 0);
/* Use put_unaligned() because stats may not be aligned for u64. */
put_unaligned(items, &stats[0]);
+
+ for_each_possible_cpu(c)
+ for (i = 1; i < items; i++)
+ buff[i] += snmp_get_cpu_field64(mib, c, i, syncpoff);
+
for (i = 1; i < items; i++)
- put_unaligned(snmp_fold_field64(mib, i, syncpoff), &stats[i]);
+ put_unaligned(buff[i], &stats[i]);
memset(&stats[items], 0, pad);
}
@@ -4641,10 +4647,12 @@ static inline void __snmp6_fill_stats64(u64 *stats, void __percpu *mib,
static void snmp6_fill_stats(u64 *stats, struct inet6_dev *idev, int attrtype,
int bytes)
{
+ u64 buff[IPSTATS_MIB_MAX] = {0,};
+
switch (attrtype) {
case IFLA_INET6_STATS:
- __snmp6_fill_stats64(stats, idev->stats.ipv6,
- IPSTATS_MIB_MAX, bytes, offsetof(struct ipstats_mib, syncp));
+ __snmp6_fill_stats64(stats, idev->stats.ipv6, IPSTATS_MIB_MAX, bytes,
+ offsetof(struct ipstats_mib, syncp), buff);
break;
case IFLA_INET6_ICMP6STATS:
__snmp6_fill_statsdev(stats, idev->stats.icmpv6dev->mibs, ICMP6_MIB_MAX, bytes);
--
1.7.11.7
From: Raghavendra K T <[email protected]>
Date: Wed, 26 Aug 2015 23:07:33 +0530
> @@ -4641,10 +4647,12 @@ static inline void __snmp6_fill_stats64(u64 *stats, void __percpu *mib,
> static void snmp6_fill_stats(u64 *stats, struct inet6_dev *idev, int attrtype,
> int bytes)
> {
> + u64 buff[IPSTATS_MIB_MAX] = {0,};
> +
> switch (attrtype) {
> case IFLA_INET6_STATS:
> - __snmp6_fill_stats64(stats, idev->stats.ipv6,
I would suggest using an explicit memset() here, it makes the overhead incurred
by this scheme clearer.
Thanks.
On 08/28/2015 12:08 AM, David Miller wrote:
> From: Raghavendra K T <[email protected]>
> Date: Wed, 26 Aug 2015 23:07:33 +0530
>
>> @@ -4641,10 +4647,12 @@ static inline void __snmp6_fill_stats64(u64 *stats, void __percpu *mib,
>> static void snmp6_fill_stats(u64 *stats, struct inet6_dev *idev, int attrtype,
>> int bytes)
>> {
>> + u64 buff[IPSTATS_MIB_MAX] = {0,};
>> +
>> switch (attrtype) {
>> case IFLA_INET6_STATS:
>> - __snmp6_fill_stats64(stats, idev->stats.ipv6,
>
> I would suggest using an explicit memset() here, it makes the overhead incurred
> by this scheme clearer.
>
I changed the code to look like below to measure fill_stat overhead:
container creation now took: 3.012s
it was:
without patch : 6.86sec
with current patch: 3.34sec
and perf did not show the snmp6_fill_stats() parent traces.
changed code:
snmp6_fill_stats(...)
{
switch (attrtype) {
case IFLA_INET6_STATS:
put_unaligned(IPSTATS_MIB_MAX, &stats[0]);
memset(&stats[1], 0, IPSTATS_MIB_MAX-1);
//__snmp6_fill_stats64(stats, idev->stats.ipv6,
IPSTATS_MIB_MAX, bytes,
// offsetof(struct ipstats_mib,
syncp), buff);
.....
}
So in summary:
The current patch amounts to reduction in major overhead in fill_stat,
though there is still percpu walk overhead (0.33sec difference).
[ percpu walk overead grows when create for e.g. 3k containers].
cache miss: there was no major difference (around 1.4%) w.r.t patch
Hi David,
hope you wanted to know the overhead than to change the current patch.
please let me know..
Eric, does V2 patch look good now.. please add your ack/review
Details:
time
=========================
time docker run -itd ubuntu:15.04 /bin/bash
b6670c321b5957f004e281cbb14512deafd0c0be6a39707c2f3dc95649bbc394
real 0m3.012s
user 0m0.093s
sys 0m0.009s
perf:
==========
# Samples: 18K of event 'cycles'
# Event count (approx.): 12838752009
# Overhead Command Shared Object Symbol
# ........ ............... ..................... ............
#
15.29% swapper [kernel.kallsyms] [k] snooze_loop
9.37% docker docker [.] scanblock
6.47% docker [kernel.kallsyms] [k] veth_stats_one
3.87% swapper [kernel.kallsyms] [k] _raw_spin_lock
2.71% docker docker [.]
From: Raghavendra K T <[email protected]>
Date: Fri, 28 Aug 2015 12:09:52 +0530
> On 08/28/2015 12:08 AM, David Miller wrote:
>> From: Raghavendra K T <[email protected]>
>> Date: Wed, 26 Aug 2015 23:07:33 +0530
>>
>>> @@ -4641,10 +4647,12 @@ static inline void __snmp6_fill_stats64(u64
>>> *stats, void __percpu *mib,
>>> static void snmp6_fill_stats(u64 *stats, struct inet6_dev *idev, int
>>> attrtype,
>>> int bytes)
>>> {
>>> + u64 buff[IPSTATS_MIB_MAX] = {0,};
>>> +
...
> hope you wanted to know the overhead than to change the current
> patch. please let me know..
I want you to change that variable initializer to an explicit memset().
The compiler is emitting a memset() or similar _anyways_.
Not because it will have any impact at all upon performance, but because
of how it looks to people trying to read and understand the code.
On Fri, 2015-08-28 at 11:24 -0700, David Miller wrote:
> From: Raghavendra K T <[email protected]>
> Date: Fri, 28 Aug 2015 12:09:52 +0530
>
> > On 08/28/2015 12:08 AM, David Miller wrote:
> >> From: Raghavendra K T <[email protected]>
> >> Date: Wed, 26 Aug 2015 23:07:33 +0530
> >>
> >>> @@ -4641,10 +4647,12 @@ static inline void __snmp6_fill_stats64(u64
> >>> *stats, void __percpu *mib,
> >>> static void snmp6_fill_stats(u64 *stats, struct inet6_dev *idev, int
> >>> attrtype,
> >>> int bytes)
> >>> {
> >>> + u64 buff[IPSTATS_MIB_MAX] = {0,};
> >>> +
> ...
> > hope you wanted to know the overhead than to change the current
> > patch. please let me know..
>
> I want you to change that variable initializer to an explicit memset().
>
> The compiler is emitting a memset() or similar _anyways_.
>
> Not because it will have any impact at all upon performance, but because
> of how it looks to people trying to read and understand the code.
I don't read it as particularly different.
There are > 100 uses of the not quite a memset initialization
style using "= { <0,> }" in net/
$ git grep -E "=\s*\{\s*0?\s*,?\s*\}" net | wc -l
138
There is a difference though if a struct is copied to
user-space as a {} initialization only guarantees that
struct members are initialized to 0 where memset also
zeros any alignment padding.
Maybe a checkpatch rule like this?
---
scripts/checkpatch.pl | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e14dcdb..f79e5c9 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3237,6 +3237,13 @@ sub process {
next;
}
+# check for non-global initializations that could be memset
+ if ($realfile =~ m@^(drivers/net/|net/)@ &&
+ $sline =~ /^.\s+$Declare\s*$Ident\s*=\s*\{\s*0?\s*,?\s*\}/) {
+ CHK("BRACE_INITIALIZATION",
+ "Prefer an explicit memset to a declaration initialization\n" . $herecurr);
+ }
+
# check for initialisation to aggregates open brace on the next line
if ($line =~ /^.\s*{/ &&
$prevline =~ /(?:^|[^=])=\s*$/) {
On Fri, 2015-08-28 at 12:20 -0700, Joe Perches wrote:
> I don't read it as particularly different.
>
> There are > 100 uses of the not quite a memset initialization
> style using "= { <0,> }" in net/
>
> $ git grep -E "=\s*\{\s*0?\s*,?\s*\}" net | wc -l
> 138
>
> There is a difference though if a struct is copied to
> user-space as a {} initialization only guarantees that
> struct members are initialized to 0 where memset also
> zeros any alignment padding.
We do not bother for small struct.
Here, the array is big enough that David prefers having an explicit
memset() so that it clearly shows that author of this code was aware of
this.
On Fri, 2015-08-28 at 13:33 -0700, Eric Dumazet wrote:
> We do not bother for small struct.
>
> Here, the array is big enough that David prefers having an explicit
> memset() so that it clearly shows that author of this code was aware of
> this.
It's 288 bytes on stack, maybe a kzalloc would be clearer too.
On Fri, 2015-08-28 at 13:53 -0700, Joe Perches wrote:
> On Fri, 2015-08-28 at 13:33 -0700, Eric Dumazet wrote:
> > We do not bother for small struct.
> >
> > Here, the array is big enough that David prefers having an explicit
> > memset() so that it clearly shows that author of this code was aware of
> > this.
>
> It's 288 bytes on stack, maybe a kzalloc would be clearer too.
Could you read patch history and check why this has been rejected ?
Thank you.
On Fri, 2015-08-28 at 13:55 -0700, Eric Dumazet wrote:
> On Fri, 2015-08-28 at 13:53 -0700, Joe Perches wrote:
> > On Fri, 2015-08-28 at 13:33 -0700, Eric Dumazet wrote:
> > > We do not bother for small struct.
> > >
> > > Here, the array is big enough that David prefers having an explicit
> > > memset() so that it clearly shows that author of this code was aware of
> > > this.
> >
> > It's 288 bytes on stack, maybe a kzalloc would be clearer too.
>
> Could you read patch history and check why this has been rejected ?
I don't see a rejection, just that the initial
submission didn't check the allocation or add
an allocation buffer via kcalloc/kzalloc to the
inet6_fill_ifla6_attrs caller and change the
snmp6_fill_stats arguments.
It could also eliminate the put_unaligned calls.
https://lkml.org/lkml/2015/8/25/114
Was there some other thread?
On Fri, 2015-08-28 at 14:09 -0700, Joe Perches wrote:
> On Fri, 2015-08-28 at 13:55 -0700, Eric Dumazet wrote:
> > On Fri, 2015-08-28 at 13:53 -0700, Joe Perches wrote:
> > > On Fri, 2015-08-28 at 13:33 -0700, Eric Dumazet wrote:
> > > > We do not bother for small struct.
> > > >
> > > > Here, the array is big enough that David prefers having an explicit
> > > > memset() so that it clearly shows that author of this code was aware of
> > > > this.
> > >
> > > It's 288 bytes on stack, maybe a kzalloc would be clearer too.
> >
> > Could you read patch history and check why this has been rejected ?
>
> I don't see a rejection, just that the initial
> submission didn't check the allocation or add
> an allocation buffer via kcalloc/kzalloc to the
> inet6_fill_ifla6_attrs caller and change the
> snmp6_fill_stats arguments.
>
> It could also eliminate the put_unaligned calls.
Not really. You do not properly read this code.
put_unaligned is happening on a space allocated from rtnetlink skb, not
the temp space needed to perform the per cpu folding.
>
> https://lkml.org/lkml/2015/8/25/114
>
> Was there some other thread?
Same thread
https://lkml.org/lkml/2015/8/25/476
On Fri, 2015-08-28 at 14:14 -0700, Eric Dumazet wrote:
> On Fri, 2015-08-28 at 14:09 -0700, Joe Perches wrote:
> > On Fri, 2015-08-28 at 13:55 -0700, Eric Dumazet wrote:
> > > On Fri, 2015-08-28 at 13:53 -0700, Joe Perches wrote:
> > > > It's 288 bytes on stack, maybe a kzalloc would be clearer too.
> > >
> > > Could you read patch history and check why this has been rejected ?
> >
> > I don't see a rejection, just that the initial
> > submission didn't check the allocation or add
> > an allocation buffer via kcalloc/kzalloc to the
> > inet6_fill_ifla6_attrs caller and change the
> > snmp6_fill_stats arguments.
> >
> > It could also eliminate the put_unaligned calls.
>
> Not really. You do not properly read this code.
Always a possibility, but I don't think so.
> put_unaligned is happening on a space allocated from rtnetlink skb, not
> the temp space needed to perform the per cpu folding.
That's why I suggested changing the snmp_fill_stats arguments.
If the naturally aligned allocated u64 array is used and then
copied as a block to the rtnetlink skb, I believe there's no
alignment issue that would require put_unaligned.
Do I still miss something?
> https://lkml.org/lkml/2015/8/25/476
I read that.
On Fri, 2015-08-28 at 14:26 -0700, Joe Perches wrote:
> Always a possibility, but I don't think so.
>
> > put_unaligned is happening on a space allocated from rtnetlink skb, not
> > the temp space needed to perform the per cpu folding.
>
> That's why I suggested changing the snmp_fill_stats arguments.
>
> If the naturally aligned allocated u64 array is used and then
> copied as a block to the rtnetlink skb, I believe there's no
> alignment issue that would require put_unaligned.
1) u64 array[XX] on stack is naturally aligned,
kzalloc() wont improve this at all. Not sure what you believe.
2) put_unaligned() is basically a normal memory write on x86.
memcpy(dst,src,...) will have a problem anyway on arches that care,
because src & dst wont have same alignment.
288 bytes on stack in a leaf function in this path is totally fine, it
is not like we're calling ext4/xfs/nfs code after this point.
On Fri, 2015-08-28 at 15:29 -0700, Eric Dumazet wrote:
> On Fri, 2015-08-28 at 14:26 -0700, Joe Perches wrote:
> 1) u64 array[XX] on stack is naturally aligned,
Of course it is.
> kzalloc() wont improve this at all. Not sure what you believe.
An alloc would only reduce stack use.
Copying into the buffer, then copying the buffer into the
skb may be desirable on some arches though.
> 2) put_unaligned() is basically a normal memory write on x86.
> memcpy(dst,src,...) will have a problem anyway on arches that care,
> because src & dst wont have same alignment.
OK, so all the world's an x86?
On arm32, copying 288 bytes using nearly all aligned word
transfers is generally faster than using only unsigned
short transfers.
> 288 bytes on stack in a leaf function in this path is totally fine, it
> is not like we're calling ext4/xfs/nfs code after this point.
Generally true. It's always difficult to know how much
stack has been consumed though and smaller stack frames
are generally better.
Anyway, the block copy from either the alloc'd or stack
buffer amounts only to a slight performance improvement
for arm32. It doesn't really have much other utility.
On Fri, 2015-08-28 at 16:12 -0700, Joe Perches wrote:
> Generally true. It's always difficult to know how much
> stack has been consumed though and smaller stack frames
> are generally better.
Calling kmalloc(288, GFP_KERNEL) might use way more than 288 bytes in
kernel stack on 64 bit arch.
__slab_alloc() itself for example uses 208 bytes on stack, so add all
others, and you might go above 500 bytes.
So for a _leaf_ function, it is better to declare an automatic variable,
as you in fact reduce max stack depth.
Not only it uses less kernel stack, it is also way faster, as you avoid
kmalloc()/kfree() overhead and reuse probably already hot cache lines in
kernel stack.
On Fri, 2015-08-28 at 17:06 -0700, Eric Dumazet wrote:
> On Fri, 2015-08-28 at 16:12 -0700, Joe Perches wrote:
> > Generally true. It's always difficult to know how much
> > stack has been consumed though and smaller stack frames
> > are generally better.
[]
> So for a _leaf_ function, it is better to declare an automatic variable,
> as you in fact reduce max stack depth.
That of course depends on what a "leaf" is and
whether or not any other function call in the
"leaf" consumes stack.
inet6_fill_ifla6_attrs does call other functions
(none of which has the stack frame size of k.alloc)
> Not only it uses less kernel stack, it is also way faster, as you avoid
> kmalloc()/kfree() overhead and reuse probably already hot cache lines in
> kernel stack.
yup.
You'll also never neglect to free stack like the
original RFC patch neglected to free the alloc.
cheers, Joe
On Fri, 2015-08-28 at 17:35 -0700, Joe Perches wrote:
> That of course depends on what a "leaf" is and
> whether or not any other function call in the
> "leaf" consumes stack.
>
> inet6_fill_ifla6_attrs does call other functions
> (none of which has the stack frame size of k.alloc)
Just define/use this automatic array in the damn leaf function.
That should not be hard, and maybe no one will complain and we can
work on more complex issues.
* David Miller <[email protected]> [2015-08-28 11:24:13]:
> From: Raghavendra K T <[email protected]>
> Date: Fri, 28 Aug 2015 12:09:52 +0530
>
> > On 08/28/2015 12:08 AM, David Miller wrote:
> >> From: Raghavendra K T <[email protected]>
> >> Date: Wed, 26 Aug 2015 23:07:33 +0530
> >>
> >>> @@ -4641,10 +4647,12 @@ static inline void __snmp6_fill_stats64(u64
> >>> *stats, void __percpu *mib,
> >>> static void snmp6_fill_stats(u64 *stats, struct inet6_dev *idev, int
> >>> attrtype,
> >>> int bytes)
> >>> {
> >>> + u64 buff[IPSTATS_MIB_MAX] = {0,};
> >>> +
> ...
> > hope you wanted to know the overhead than to change the current
> > patch. please let me know..
>
> I want you to change that variable initializer to an explicit memset().
>
> The compiler is emitting a memset() or similar _anyways_.
>
> Not because it will have any impact at all upon performance, but because
> of how it looks to people trying to read and understand the code.
>
>
Hi David,
resending the patch with memset. Please let me know if you want to
resend all the patches.
----8<----
From: Raghavendra K T <[email protected]>
Subject: [PATCH RFC V2 2/2] net: Optimize snmp stat aggregation by walking
all the percpu data at once
Docker container creation linearly increased from around 1.6 sec to 7.5 sec
(at 1000 containers) and perf data showed 50% ovehead in snmp_fold_field.
reason: currently __snmp6_fill_stats64 calls snmp_fold_field that walks
through per cpu data of an item (iteratively for around 90 items).
idea: This patch tries to aggregate the statistics by going through
all the items of each cpu sequentially which is reducing cache
misses.
Docker creation got faster by more than 2x after the patch.
Result:
Before After
Docker creation time 6.836s 3.357s
cache miss 2.7% 1.38%
perf before:
50.73% docker [kernel.kallsyms] [k] snmp_fold_field
9.07% swapper [kernel.kallsyms] [k] snooze_loop
3.49% docker [kernel.kallsyms] [k] veth_stats_one
2.85% swapper [kernel.kallsyms] [k] _raw_spin_lock
perf after:
10.56% swapper [kernel.kallsyms] [k] snooze_loop
8.72% docker [kernel.kallsyms] [k] snmp_get_cpu_field
7.59% docker [kernel.kallsyms] [k] veth_stats_one
3.65% swapper [kernel.kallsyms] [k] _raw_spin_lock
Signed-off-by: Raghavendra K T <[email protected]>
---
net/ipv6/addrconf.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
Change in V2:
- Allocate stat calculation buffer in stack (Eric)
- Use memset to zero temp buffer (David)
Thanks David and Eric for coments on V1 and as both of them pointed,
unfortunately we cannot get rid of buffer for calculation without
avoiding unaligned op.
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 21c2c81..9bdfba3 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -4624,16 +4624,22 @@ static inline void __snmp6_fill_statsdev(u64 *stats, atomic_long_t *mib,
}
static inline void __snmp6_fill_stats64(u64 *stats, void __percpu *mib,
- int items, int bytes, size_t syncpoff)
+ int items, int bytes, size_t syncpoff,
+ u64 *buff)
{
- int i;
+ int i, c;
int pad = bytes - sizeof(u64) * items;
BUG_ON(pad < 0);
/* Use put_unaligned() because stats may not be aligned for u64. */
put_unaligned(items, &stats[0]);
+
+ for_each_possible_cpu(c)
+ for (i = 1; i < items; i++)
+ buff[i] += snmp_get_cpu_field64(mib, c, i, syncpoff);
+
for (i = 1; i < items; i++)
- put_unaligned(snmp_fold_field64(mib, i, syncpoff), &stats[i]);
+ put_unaligned(buff[i], &stats[i]);
memset(&stats[items], 0, pad);
}
@@ -4641,10 +4647,13 @@ static inline void __snmp6_fill_stats64(u64 *stats, void __percpu *mib,
static void snmp6_fill_stats(u64 *stats, struct inet6_dev *idev, int attrtype,
int bytes)
{
+ u64 buff[IPSTATS_MIB_MAX];
+
switch (attrtype) {
case IFLA_INET6_STATS:
- __snmp6_fill_stats64(stats, idev->stats.ipv6,
- IPSTATS_MIB_MAX, bytes, offsetof(struct ipstats_mib, syncp));
+ memset(buff, 0, sizeof(buff));
+ __snmp6_fill_stats64(stats, idev->stats.ipv6, IPSTATS_MIB_MAX, bytes,
+ offsetof(struct ipstats_mib, syncp), buff);
break;
case IFLA_INET6_ICMP6STATS:
__snmp6_fill_statsdev(stats, idev->stats.icmpv6dev->mibs, ICMP6_MIB_MAX, bytes);
--
1.7.11.7
On Sat, 2015-08-29 at 08:27 +0530, Raghavendra K T wrote:
>
> /* Use put_unaligned() because stats may not be aligned for u64. */
> put_unaligned(items, &stats[0]);
> for (i = 1; i < items; i++)
> - put_unaligned(snmp_fold_field64(mib, i, syncpoff), &stats[i]);
> + put_unaligned(buff[i], &stats[i]);
>
I believe Joe suggested following code instead :
buff[0] = items;
memcpy(stats, buff, items * sizeof(u64));
Also please move buff[] array into __snmp6_fill_stats64() to make it
clear it is used in a 'leaf' function.
(even if calling memcpy()/memset() makes it not a leaf function)
From: Raghavendra K T <[email protected]>
Date: Sat, 29 Aug 2015 08:27:15 +0530
> resending the patch with memset. Please let me know if you want to
> resend all the patches.
Do not post patches as replies to existing discussion threads.
Instead, make a new, fresh, patch posting, updating the Subject line
as needed.
On 08/29/2015 08:56 AM, Eric Dumazet wrote:
> On Sat, 2015-08-29 at 08:27 +0530, Raghavendra K T wrote:
>>
>> /* Use put_unaligned() because stats may not be aligned for u64. */
>> put_unaligned(items, &stats[0]);
>
>
>> for (i = 1; i < items; i++)
>> - put_unaligned(snmp_fold_field64(mib, i, syncpoff), &stats[i]);
>> + put_unaligned(buff[i], &stats[i]);
>>
>
> I believe Joe suggested following code instead :
>
> buff[0] = items;
> memcpy(stats, buff, items * sizeof(u64));
Thanks. Sure, will use this.
(I missed that. I thought that it was applicable only when we have
aligned data,and for power, put_aunaligned was not a nop unlike intel).
>
> Also please move buff[] array into __snmp6_fill_stats64() to make it
> clear it is used in a 'leaf' function.
Correct.
>
> (even if calling memcpy()/memset() makes it not a leaf function)
>
On 08/29/2015 10:41 AM, David Miller wrote:
> From: Raghavendra K T <[email protected]>
> Date: Sat, 29 Aug 2015 08:27:15 +0530
>
>> resending the patch with memset. Please let me know if you want to
>> resend all the patches.
>
> Do not post patches as replies to existing discussion threads.
>
> Instead, make a new, fresh, patch posting, updating the Subject line
> as needed.
>
Sure.