| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 10 May 2016 15:44:06 -0700 From: Eric Dumazet <eric.dumazet@...il.com> To: Rik van Riel <riel@...hat.com> Cc: Eric Dumazet <edumazet@...gle.com>, Hannes Frederic Sowa <hannes@...essinduktion.org>, Paolo Abeni <pabeni@...hat.com>, netdev <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Jiri Pirko <jiri@...lanox.com>, Daniel Borkmann <daniel@...earbox.net>, Alexei Starovoitov <ast@...mgrid.com>, Alexander Duyck <aduyck@...antis.com>, Tom Herbert <tom@...bertland.com>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH 0/2] net: threadable napi poll loop On Tue, 2016-05-10 at 15:02 -0700, Eric Dumazet wrote: > On Tue, 2016-05-10 at 14:53 -0700, Eric Dumazet wrote: > > On Tue, 2016-05-10 at 17:35 -0400, Rik van Riel wrote: > > > > > You might need another one of these in invoke_softirq() > > > > > > > Excellent. > > > > I gave it a quick try (without your suggestion), and host seems to > > survive a stress test. > > > > Of course we do have to fix these problems : > > > > [ 147.781629] NOHZ: local_softirq_pending 48 > > [ 147.785546] NOHZ: local_softirq_pending 48 > > [ 147.788344] NOHZ: local_softirq_pending 48 > > [ 147.788992] NOHZ: local_softirq_pending 48 > > [ 147.790943] NOHZ: local_softirq_pending 48 > > [ 147.791232] NOHZ: local_softirq_pending 24a > > [ 147.791258] NOHZ: local_softirq_pending 48 > > [ 147.791366] NOHZ: local_softirq_pending 48 > > [ 147.792118] NOHZ: local_softirq_pending 48 > > [ 147.793428] NOHZ: local_softirq_pending 48 > > > Well, with your suggestion, these warnings disappear ;) This is really nice. Under stress number of context switches is really small. ksoftirqd and my netserver compete equally to get the cpu cycles (on CPU0) lpaa23:~# vmstat 1 10 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 2 0 0 260668416 37240 2414428 0 0 21 0 329 349 0 3 96 0 1 0 0 260667904 37240 2414428 0 0 0 12 193126 1050 0 2 98 0 1 0 0 260667904 37240 2414428 0 0 0 0 194354 1056 0 2 98 0 1 0 0 260669104 37240 2414492 0 0 0 0 200897 1095 0 2 98 0 1 0 0 260668592 37240 2414492 0 0 0 0 205731 964 0 2 98 0 1 0 0 260678832 37240 2414492 0 0 0 0 201689 981 0 2 98 0 1 0 0 260678832 37240 2414492 0 0 0 0 204899 742 0 2 98 0 1 0 0 260678320 37240 2414492 0 0 0 0 199148 792 0 3 97 0 1 0 0 260678832 37240 2414492 0 0 0 0 196398 766 0 2 98 0 1 0 0 260678832 37240 2414492 0 0 0 0 201930 858 0 2 98 0 And we can see that ksoftirqd/0 runs for longer periods (~500 usec), instead of stupid 4 usec before the patch. Less overhead. lpaa23:~# cat /proc/3/sched ksoftirqd/0 (3, #threads: 1) ------------------------------------------------------------------- se.exec_start : 1552401.399526 se.vruntime : 237599.421560 se.sum_exec_runtime : 75432.494199 se.nr_migrations : 0 nr_switches : 144333 nr_voluntary_switches : 143828 nr_involuntary_switches : 505 se.load.weight : 1024 se.avg.load_sum : 10445 se.avg.util_sum : 10445 se.avg.load_avg : 0 se.avg.util_avg : 0 se.avg.last_update_time : 1552401399526 policy : 0 prio : 120 clock-delta : 47 lpaa23:~# echo 75432.494199/144333|bc -l .52262818758703830724 And yes indeed, user space can progress way faster under flood. lpaa23:~# nstat >/dev/null;sleep 1;nstat | grep Udp UdpInDatagrams 186132 0.0 UdpInErrors 735462 0.0 UdpOutDatagrams 10 0.0 UdpRcvbufErrors 735461 0.0
Powered by blists - more mailing lists