On Tue, Mar 8, 2016 at 6:37 PM, Ingo Molnar <mi...@kernel.org> wrote: > > * Dmitry Vyukov <dvyu...@google.com> wrote: > >> > fomalhaut:~/go/src/github.com/google/syzkaller> ps aux | grep -i syz >> > mingo 1374 0.0 0.0 118476 2376 pts/2 S+ 18:23 0:00 grep >> > --color=auto -i syz >> > >> > and with no kernel messages in dmesg - and with a fully functional system. >> > >> > I'm running the 16-task load on a 120 CPU system - should I increase it to >> > 120? >> > Does the code expect to saturate the system? >> >> No, it does not expect to saturate the system. Set "procs" to 480, or >> something like that. > > Does not seem to help much: > > fomalhaut:~> vmstat 10 > procs -----------memory---------- ---swap-- -----io---- -system-- > ------cpu----- > r b swpd free buff cache si so bi bo in cs us sy id wa > st > > 1 0 0 257465904 219940 4736092 0 0 0 102 16022 4396 0 1 > 99 0 0 > 2 0 0 257452144 220496 4755052 0 0 2 3649 14286 4627 0 1 > 99 0 0 > 2 0 0 257473408 221188 4770824 0 0 15 1898 17175 4474 0 1 > 99 0 0 > > Only around 1% system utilization. Should I go for 1,000 or more? :) > > Peter, do you experience with running syz-kaller on larger CPU count Intel > systems?
Try to set "dropprivs": false in config. I've noticed that creation/destruction of namespaces is very slow and globally serialized. So sometimes it takes tens of seconds for each worker processes to startup. For perf-related syscalls it should be "safe" to just run as root. And perf subsystem operation is also unaffected by namespaces as far as I know, so it should not affect behavior as well.
