* 4.9 conntrack performance issues
@ 2017-01-14 23:05 Denys Fedoryshchenko
2017-01-14 23:53 ` Florian Westphal
2017-01-30 11:26 ` Guillaume Nault
0 siblings, 2 replies; 8+ messages in thread
From: Denys Fedoryshchenko @ 2017-01-14 23:05 UTC (permalink / raw)
To: Guillaume Nault, Netfilter Devel, Pablo Neira Ayuso,
Linux Kernel Network Developers
Hi!
Sorry if i added someone wrongly to CC, please let me know, if i should
remove.
I just run successfully 4.9 on my nat several days ago, and seems panic
issue disappeared. But i started to face another issue, it seems garbage
collector is hogging one of CPU's.
Here is my data:
2xE5-2640 v3
396G ram
2x10G (bonding) with approx 14-15G load at peak time
It was handling load very well at 4.8 and below, it might be still fine,
but i suspect queues that belong to hogged cpu might experience issues.
Is there anything can be done to improve cpu load distribution or reduce
single core load?
net.netfilter.nf_conntrack_buckets = 65536
net.netfilter.nf_conntrack_checksum = 1
net.netfilter.nf_conntrack_count = 1236021
net.netfilter.nf_conntrack_events = 1
net.netfilter.nf_conntrack_expect_max = 1024
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_helper = 0
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_max = 6553600
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_loose = 0
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 10
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 20
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 20
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 10
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 20
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 20
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 30
net.netfilter.nf_conntrack_timestamp = 0
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.nf_conntrack_max = 6553600
it is non-peak values, as adjustments i have shorter than default
timeouts. Changing net.netfilter.nf_conntrack_buckets to higher value
doesn't fix issue.
I noticed that one of CPU's hogged (N24 in this case):
Linux 4.9.2-build-0127 (NAT) 01/14/17 _x86_64_ (32 CPU)
23:01:54 CPU %usr %nice %sys %iowait %irq %soft %steal
%guest %idle
23:02:04 all 0.09 0.00 1.60 0.01 0.00 28.28 0.00
0.00 70.01
23:02:04 0 0.11 0.00 0.00 0.00 0.00 32.38 0.00
0.00 67.51
23:02:04 1 0.12 0.00 0.12 0.00 0.00 29.91 0.00
0.00 69.86
23:02:04 2 0.23 0.00 0.11 0.00 0.00 29.57 0.00
0.00 70.09
23:02:04 3 0.11 0.00 0.11 0.11 0.00 28.80 0.00
0.00 70.86
23:02:04 4 0.23 0.00 0.11 0.11 0.00 31.41 0.00
0.00 68.14
23:02:04 5 0.11 0.00 0.00 0.00 0.00 29.28 0.00
0.00 70.61
23:02:04 6 0.11 0.00 0.11 0.00 0.00 31.81 0.00
0.00 67.96
23:02:04 7 0.11 0.00 0.11 0.00 0.00 32.69 0.00
0.00 67.08
23:02:04 8 0.00 0.00 0.23 0.00 0.00 42.12 0.00
0.00 57.64
23:02:04 9 0.11 0.00 0.00 0.00 0.00 30.86 0.00
0.00 69.02
23:02:04 10 0.11 0.00 0.11 0.00 0.00 30.93 0.00
0.00 68.84
23:02:04 11 0.00 0.00 0.11 0.00 0.00 32.73 0.00
0.00 67.16
23:02:04 12 0.11 0.00 0.11 0.00 0.00 29.85 0.00
0.00 69.92
23:02:04 13 0.00 0.00 0.00 0.00 0.00 30.96 0.00
0.00 69.04
23:02:04 14 0.00 0.00 0.00 0.00 0.00 30.09 0.00
0.00 69.91
23:02:04 15 0.00 0.00 0.11 0.00 0.00 30.63 0.00
0.00 69.26
23:02:04 16 0.11 0.00 0.00 0.00 0.00 25.88 0.00
0.00 74.01
23:02:04 17 0.11 0.00 0.00 0.00 0.00 22.82 0.00
0.00 77.07
23:02:04 18 0.11 0.00 0.00 0.00 0.00 23.75 0.00
0.00 76.14
23:02:04 19 0.11 0.00 0.11 0.00 0.00 24.86 0.00
0.00 74.92
23:02:04 20 0.11 0.00 0.11 0.11 0.00 24.48 0.00
0.00 75.19
23:02:04 21 0.22 0.00 0.11 0.00 0.00 23.43 0.00
0.00 76.24
23:02:04 22 0.11 0.00 0.11 0.00 0.00 25.46 0.00
0.00 74.32
23:02:04 23 0.00 0.00 0.11 0.00 0.00 25.47 0.00
0.00 74.41
23:02:04 24 0.00 0.00 45.06 0.00 0.00 42.18 0.00
0.00 12.76
23:02:04 25 0.11 0.00 0.11 0.11 0.00 25.22 0.00
0.00 74.46
23:02:04 26 0.11 0.00 0.00 0.11 0.00 23.39 0.00
0.00 76.39
23:02:04 27 0.22 0.00 0.11 0.00 0.00 23.83 0.00
0.00 75.85
23:02:04 28 0.11 0.00 0.11 0.00 0.00 24.10 0.00
0.00 75.68
23:02:04 29 0.11 0.00 0.11 0.00 0.00 23.80 0.00
0.00 75.98
23:02:04 30 0.11 0.00 0.11 0.00 0.00 23.45 0.00
0.00 76.33
23:02:04 31 0.11 0.00 0.11 0.00 0.00 20.37 0.00
0.00 79.42
And this is output of ./perf top -C 24 -e cycles
PerfTop: 933 irqs/sec kernel:100.0% exact: 0.0% [1000Hz
cycles], (all, CPU: 24)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
52.68% [nf_conntrack] [k] gc_worker
3.88% [ip_tables] [k] ipt_do_table
2.39% [ixgbe] [k] ixgbe_xmit_frame_ring
2.29% [kernel] [k] _raw_spin_lock
1.84% [ixgbe] [k] ixgbe_poll
1.76% [nf_conntrack] [k] __nf_conntrack_find_get
perf report for this cpu (same, cycles)
# Children Self Command Shared Object Symbol
# ........ ........ ............ ......................
....................................................
#
88.98% 0.00% kworker/24:1 [kernel.kallsyms] [k]
process_one_work
|
---process_one_work
|
|--54.65%--gc_worker
| |
| --3.58%--nf_ct_gc_expired
| |
| |--1.90%--nf_ct_delete
| | |
| |
--1.31%--nf_ct_delete_from_lists
| |
| --1.61%--nf_conntrack_destroy
| destroy_conntrack
| |
|
--1.53%--nf_conntrack_free
| |
|
|--0.80%--kmem_cache_free
| | |
| |
--0.51%--__slab_free.isra.12
| |
|
--0.52%--__nf_ct_ext_destroy
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 4.9 conntrack performance issues
2017-01-14 23:05 4.9 conntrack performance issues Denys Fedoryshchenko
@ 2017-01-14 23:53 ` Florian Westphal
2017-01-15 0:18 ` Denys Fedoryshchenko
2017-01-30 11:26 ` Guillaume Nault
1 sibling, 1 reply; 8+ messages in thread
From: Florian Westphal @ 2017-01-14 23:53 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Guillaume Nault, Netfilter Devel, Pablo Neira Ayuso,
Linux Kernel Network Developers, nicolas.dichtel
Denys Fedoryshchenko <nuclearcat@nuclearcat.com> wrote:
[ CC Nicolas since he also played with gc heuristics in the past ]
> Sorry if i added someone wrongly to CC, please let me know, if i should
> remove.
> I just run successfully 4.9 on my nat several days ago, and seems panic
> issue disappeared. But i started to face another issue, it seems garbage
> collector is hogging one of CPU's.
>
> It was handling load very well at 4.8 and below, it might be still fine, but
> i suspect queues that belong to hogged cpu might experience issues.
The worker doesn't grab locks for long and calls scheduler for every
bucket to give a chance for other threads to run.
It also doesn't block softinterrupts.
> Is there anything can be done to improve cpu load distribution or reduce
> single core load?
No, I am afraid we don't export any of the heuristics as tuneables so
far.
You could try changing defaults in net/netfilter/nf_conntrack_core.c:
#define GC_MAX_BUCKETS_DIV 64u
/* upper bound of scan intervals */
#define GC_INTERVAL_MAX (2 * HZ)
/* maximum conntracks to evict per gc run */
#define GC_MAX_EVICTS 256u
(the first two result in ~2 minute worst case timeout detection
on a fully idle system).
For instance you could use
GC_MAX_BUCKETS_DIV -> 128
GC_INTERVAL_MAX -> 30 * HZ
(This means that it takes one hour for a dead connection to be picked
up on an idle system, but thats only relevant in case you use
conntrack events to log when connection went down and need more precise
accounting).
I suspect you might also have to change
1011 } else if (expired_count) {
1012 gc_work->next_gc_run /= 2U;
1013 next_run = msecs_to_jiffies(1);
1014 } else {
line 2013 to
next_run = msecs_to_jiffies(HZ / 2);
or something like this to not have frequent rescans.
The gc is also done from the packet path (i.e. accounted
towards (k)softirq).
How many total connections is the machine handling on average?
And how many new/delete events happen per second?
> 88.98% 0.00% kworker/24:1 [kernel.kallsyms] [k]
> process_one_work
> |
> ---process_one_work
> |
> |--54.65%--gc_worker
> | |
> | --3.58%--nf_ct_gc_expired
> | |
> | |--1.90%--nf_ct_delete
I'd be interested to see how often that shows up on other cores
(from packet path).
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 4.9 conntrack performance issues
2017-01-14 23:53 ` Florian Westphal
@ 2017-01-15 0:18 ` Denys Fedoryshchenko
2017-01-15 0:29 ` Florian Westphal
0 siblings, 1 reply; 8+ messages in thread
From: Denys Fedoryshchenko @ 2017-01-15 0:18 UTC (permalink / raw)
To: Florian Westphal
Cc: Guillaume Nault, Netfilter Devel, Pablo Neira Ayuso,
Linux Kernel Network Developers, nicolas.dichtel, netdev-owner
On 2017-01-15 01:53, Florian Westphal wrote:
> Denys Fedoryshchenko <nuclearcat@nuclearcat.com> wrote:
>
> [ CC Nicolas since he also played with gc heuristics in the past ]
>
>> Sorry if i added someone wrongly to CC, please let me know, if i
>> should
>> remove.
>> I just run successfully 4.9 on my nat several days ago, and seems
>> panic
>> issue disappeared. But i started to face another issue, it seems
>> garbage
>> collector is hogging one of CPU's.
>>
>> It was handling load very well at 4.8 and below, it might be still
>> fine, but
>> i suspect queues that belong to hogged cpu might experience issues.
>
> The worker doesn't grab locks for long and calls scheduler for every
> bucket to give a chance for other threads to run.
>
> It also doesn't block softinterrupts.
>
>> Is there anything can be done to improve cpu load distribution or
>> reduce
>> single core load?
>
> No, I am afraid we don't export any of the heuristics as tuneables so
> far.
>
> You could try changing defaults in net/netfilter/nf_conntrack_core.c:
>
> #define GC_MAX_BUCKETS_DIV 64u
> /* upper bound of scan intervals */
> #define GC_INTERVAL_MAX (2 * HZ)
> /* maximum conntracks to evict per gc run */
> #define GC_MAX_EVICTS 256u
>
> (the first two result in ~2 minute worst case timeout detection
> on a fully idle system).
>
> For instance you could use
>
> GC_MAX_BUCKETS_DIV -> 128
> GC_INTERVAL_MAX -> 30 * HZ
>
> (This means that it takes one hour for a dead connection to be picked
> up on an idle system, but thats only relevant in case you use
> conntrack events to log when connection went down and need more
> precise
> accounting).
Not a big deal in my case.
>
> I suspect you might also have to change
>
> 1011 } else if (expired_count) {
> 1012 gc_work->next_gc_run /= 2U;
> 1013 next_run = msecs_to_jiffies(1);
> 1014 } else {
>
> line 2013 to
> next_run = msecs_to_jiffies(HZ / 2);
>
> or something like this to not have frequent rescans.
OK
>
> The gc is also done from the packet path (i.e. accounted
> towards (k)softirq).
>
> How many total connections is the machine handling on average?
> And how many new/delete events happen per second?
1-2 million connections, at current moment 988k
I dont know if it is correct method to measure events rate:
NAT ~ # timeout -t 5 conntrack -E -e NEW | wc -l
conntrack v1.4.2 (conntrack-tools): 40027 flow events have been shown.
40027
NAT ~ # timeout -t 5 conntrack -E -e DESTROY | wc -l
conntrack v1.4.2 (conntrack-tools): 40951 flow events have been shown.
40951
It is not peak time, so values can be 2-3 higher at peak time, but even
right now, it is hogging one core, leaving only 20% idle left,
while others are 80-83% idle.
>
>> 88.98% 0.00% kworker/24:1 [kernel.kallsyms] [k]
>> process_one_work
>> |
>> ---process_one_work
>> |
>> |--54.65%--gc_worker
>> | |
>> | --3.58%--nf_ct_gc_expired
>> | |
>> | |--1.90%--nf_ct_delete
>
> I'd be interested to see how often that shows up on other cores
> (from packet path).
Other CPU's totally different:
This is top entry
99.60% 0.00% swapper [kernel.kallsyms] [k] start_secondary
|
---start_secondary
|
--99.42%--cpu_startup_entry
|
--98.04%--default_idle_call
arch_cpu_idle
|
|--48.58%--call_function_single_interrupt
| |
|
--46.36%--smp_call_function_single_interrupt
|
smp_trace_call_function_single_interrupt
| |
|
|--44.18%--irq_exit
| | |
| |
|--43.37%--__do_softirq
| | |
|
| | |
--43.18%--net_rx_action
| | |
|
| | |
|--36.02%--process_backlog
| | |
| |
| | |
| --35.64%--__netif_receive_skb
gc_worker didnt appeared on other core at all.
Or i am checking something wrong?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 4.9 conntrack performance issues
2017-01-15 0:18 ` Denys Fedoryshchenko
@ 2017-01-15 0:29 ` Florian Westphal
2017-01-15 0:42 ` Denys Fedoryshchenko
0 siblings, 1 reply; 8+ messages in thread
From: Florian Westphal @ 2017-01-15 0:29 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Florian Westphal, Guillaume Nault, Netfilter Devel,
Pablo Neira Ayuso, Linux Kernel Network Developers,
nicolas.dichtel, netdev-owner
Denys Fedoryshchenko <nuclearcat@nuclearcat.com> wrote:
> On 2017-01-15 01:53, Florian Westphal wrote:
> >Denys Fedoryshchenko <nuclearcat@nuclearcat.com> wrote:
> >
> >I suspect you might also have to change
> >
> >1011 } else if (expired_count) {
> >1012 gc_work->next_gc_run /= 2U;
> >1013 next_run = msecs_to_jiffies(1);
> >1014 } else {
> >
> >line 2013 to
> > next_run = msecs_to_jiffies(HZ / 2);
I think its wrong to rely on "expired_count", with these
kinds of numbers (up to 10k entries are scanned per round
in Denys setup, its basically always going to be > 0.
I think we should only decide to scan more frequently if
eviction ratio is large, say, we found more than 1/4 of
entries to be stale.
I sent a small patch offlist that does just that.
> >How many total connections is the machine handling on average?
> >And how many new/delete events happen per second?
> 1-2 million connections, at current moment 988k
> I dont know if it is correct method to measure events rate:
>
> NAT ~ # timeout -t 5 conntrack -E -e NEW | wc -l
> conntrack v1.4.2 (conntrack-tools): 40027 flow events have been shown.
> 40027
> NAT ~ # timeout -t 5 conntrack -E -e DESTROY | wc -l
> conntrack v1.4.2 (conntrack-tools): 40951 flow events have been shown.
> 40951
Thanks, thats exactly what I was looking for.
So I am not at all surprised that gc_worker eats cpu cycles...
> It is not peak time, so values can be 2-3 higher at peak time, but even
> right now, it is hogging one core, leaving only 20% idle left,
> while others are 80-83% idle.
I agree its a bug.
> >> |--54.65%--gc_worker
> >> | |
> >> | --3.58%--nf_ct_gc_expired
> >> | |
> >> | |--1.90%--nf_ct_delete
> >
> >I'd be interested to see how often that shows up on other cores
> >(from packet path).
> Other CPU's totally different:
> This is top entry
> 99.60% 0.00% swapper [kernel.kallsyms] [k] start_secondary
> |
> ---start_secondary
> |
> --99.42%--cpu_startup_entry
> |
[..]
> |--36.02%--process_backlog
> | | |
> | |
> | | |
> | --35.64%--__netif_receive_skb
>
> gc_worker didnt appeared on other core at all.
> Or i am checking something wrong?
Look for "nf_ct_gc_expired" and "nf_ct_delete".
Its going to be deep down in the call graph.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 4.9 conntrack performance issues
2017-01-15 0:29 ` Florian Westphal
@ 2017-01-15 0:42 ` Denys Fedoryshchenko
0 siblings, 0 replies; 8+ messages in thread
From: Denys Fedoryshchenko @ 2017-01-15 0:42 UTC (permalink / raw)
To: Florian Westphal
Cc: Guillaume Nault, Netfilter Devel, Pablo Neira Ayuso,
Linux Kernel Network Developers, nicolas.dichtel, netdev-owner
On 2017-01-15 02:29, Florian Westphal wrote:
> Denys Fedoryshchenko <nuclearcat@nuclearcat.com> wrote:
>> On 2017-01-15 01:53, Florian Westphal wrote:
>> >Denys Fedoryshchenko <nuclearcat@nuclearcat.com> wrote:
>> >
>> >I suspect you might also have to change
>> >
>> >1011 } else if (expired_count) {
>> >1012 gc_work->next_gc_run /= 2U;
>> >1013 next_run = msecs_to_jiffies(1);
>> >1014 } else {
>> >
>> >line 2013 to
>> > next_run = msecs_to_jiffies(HZ / 2);
>
> I think its wrong to rely on "expired_count", with these
> kinds of numbers (up to 10k entries are scanned per round
> in Denys setup, its basically always going to be > 0.
>
> I think we should only decide to scan more frequently if
> eviction ratio is large, say, we found more than 1/4 of
> entries to be stale.
>
> I sent a small patch offlist that does just that.
>
>> >How many total connections is the machine handling on average?
>> >And how many new/delete events happen per second?
>> 1-2 million connections, at current moment 988k
>> I dont know if it is correct method to measure events rate:
>>
>> NAT ~ # timeout -t 5 conntrack -E -e NEW | wc -l
>> conntrack v1.4.2 (conntrack-tools): 40027 flow events have been shown.
>> 40027
>> NAT ~ # timeout -t 5 conntrack -E -e DESTROY | wc -l
>> conntrack v1.4.2 (conntrack-tools): 40951 flow events have been shown.
>> 40951
>
> Thanks, thats exactly what I was looking for.
> So I am not at all surprised that gc_worker eats cpu cycles...
>
>> It is not peak time, so values can be 2-3 higher at peak time, but
>> even
>> right now, it is hogging one core, leaving only 20% idle left,
>> while others are 80-83% idle.
>
> I agree its a bug.
>
>> >> |--54.65%--gc_worker
>> >> | |
>> >> | --3.58%--nf_ct_gc_expired
>> >> | |
>> >> | |--1.90%--nf_ct_delete
>> >
>> >I'd be interested to see how often that shows up on other cores
>> >(from packet path).
>> Other CPU's totally different:
>> This is top entry
>> 99.60% 0.00% swapper [kernel.kallsyms] [k]
>> start_secondary
>> |
>> ---start_secondary
>> |
>> --99.42%--cpu_startup_entry
>> |
> [..]
>
>> |--36.02%--process_backlog
>> | |
>> |
>> | |
>> | |
>> |
>> | --35.64%--__netif_receive_skb
>>
>> gc_worker didnt appeared on other core at all.
>> Or i am checking something wrong?
>
> Look for "nf_ct_gc_expired" and "nf_ct_delete".
> Its going to be deep down in the call graph.
I tried my best to record as much data as possible, but it doesnt show
it in callgraph, just a little bit in statistics:
0.01% 0.00% swapper [nf_conntrack] [k]
nf_ct_delete
0.01% 0.00% swapper [nf_conntrack] [k]
nf_ct_gc_expired
And thats it.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 4.9 conntrack performance issues
2017-01-14 23:05 4.9 conntrack performance issues Denys Fedoryshchenko
2017-01-14 23:53 ` Florian Westphal
@ 2017-01-30 11:26 ` Guillaume Nault
2017-01-30 11:37 ` Denys Fedoryshchenko
1 sibling, 1 reply; 8+ messages in thread
From: Guillaume Nault @ 2017-01-30 11:26 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Netfilter Devel, Pablo Neira Ayuso,
Linux Kernel Network Developers
On Sun, Jan 15, 2017 at 01:05:58AM +0200, Denys Fedoryshchenko wrote:
> Hi!
>
> Sorry if i added someone wrongly to CC, please let me know, if i should
> remove.
> I just run successfully 4.9 on my nat several days ago, and seems panic
> issue disappeared.
>
Hi Denys,
After two weeks running Linux 4.9, do you confirm that the original
issue[1] is gone?
Regards,
Guillaume
[1]: https://www.spinics.net/lists/netdev/msg410795.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 4.9 conntrack performance issues
2017-01-30 11:26 ` Guillaume Nault
@ 2017-01-30 11:37 ` Denys Fedoryshchenko
2017-01-30 12:21 ` Guillaume Nault
0 siblings, 1 reply; 8+ messages in thread
From: Denys Fedoryshchenko @ 2017-01-30 11:37 UTC (permalink / raw)
To: Guillaume Nault
Cc: Netfilter Devel, Pablo Neira Ayuso,
Linux Kernel Network Developers
On 2017-01-30 13:26, Guillaume Nault wrote:
> On Sun, Jan 15, 2017 at 01:05:58AM +0200, Denys Fedoryshchenko wrote:
>> Hi!
>>
>> Sorry if i added someone wrongly to CC, please let me know, if i
>> should
>> remove.
>> I just run successfully 4.9 on my nat several days ago, and seems
>> panic
>> issue disappeared.
>>
> Hi Denys,
>
> After two weeks running Linux 4.9, do you confirm that the original
> issue[1] is gone?
>
> Regards,
>
> Guillaume
>
> [1]: https://www.spinics.net/lists/netdev/msg410795.html
Yes, no more reboots at all and 4.9 patched for gc issues seems
significantly better for NAT performance (CPU load lower almost twice
than previous kernels, i dont have exact numbers).
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: 4.9 conntrack performance issues
2017-01-30 11:37 ` Denys Fedoryshchenko
@ 2017-01-30 12:21 ` Guillaume Nault
0 siblings, 0 replies; 8+ messages in thread
From: Guillaume Nault @ 2017-01-30 12:21 UTC (permalink / raw)
To: Denys Fedoryshchenko
Cc: Netfilter Devel, Pablo Neira Ayuso,
Linux Kernel Network Developers
On Mon, Jan 30, 2017 at 01:37:43PM +0200, Denys Fedoryshchenko wrote:
> On 2017-01-30 13:26, Guillaume Nault wrote:
> > On Sun, Jan 15, 2017 at 01:05:58AM +0200, Denys Fedoryshchenko wrote:
> > > Hi!
> > >
> > > Sorry if i added someone wrongly to CC, please let me know, if i
> > > should
> > > remove.
> > > I just run successfully 4.9 on my nat several days ago, and seems
> > > panic
> > > issue disappeared.
> > >
> > Hi Denys,
> >
> > After two weeks running Linux 4.9, do you confirm that the original
> > issue[1] is gone?
> >
> > Regards,
> >
> > Guillaume
> >
> > [1]: https://www.spinics.net/lists/netdev/msg410795.html
> Yes, no more reboots at all and 4.9 patched for gc issues seems
> significantly better for NAT performance (CPU load lower almost twice than
> previous kernels, i dont have exact numbers).
Great! Thanks for the feedback.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-01-30 12:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-14 23:05 4.9 conntrack performance issues Denys Fedoryshchenko
2017-01-14 23:53 ` Florian Westphal
2017-01-15 0:18 ` Denys Fedoryshchenko
2017-01-15 0:29 ` Florian Westphal
2017-01-15 0:42 ` Denys Fedoryshchenko
2017-01-30 11:26 ` Guillaume Nault
2017-01-30 11:37 ` Denys Fedoryshchenko
2017-01-30 12:21 ` Guillaume Nault
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).