[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+amJpRg9jdz1vEupJO8gsbeh7PuOKTiuvkuu7cWigY50Q@mail.gmail.com>
Date: Tue, 8 Mar 2016 17:59:55 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Wang Nan <wangnan0@...wei.com>, Ingo Molnar <mingo@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
He Kuang <hekuang@...wei.com>,
Alexei Starovoitov <ast@...nel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Brendan Gregg <brendan.d.gregg@...il.com>,
Jiri Olsa <jolsa@...nel.org>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Namhyung Kim <namhyung@...nel.org>,
Zefan Li <lizefan@...wei.com>, pi3orama@....com
Subject: Re: [RESEND PATCH 0/5] perf core: Support overwrite ring buffer
On Tue, Mar 8, 2016 at 5:48 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Ingo Molnar <mingo@...nel.org> wrote:
>
>> It only had a couple of seconds of runtime:
>>
>> 49652 mingo 20 0 1434276 52144 11344 S 0.0 0.0 0:00.54 syz-manager
>> 49661 mingo 20 0 2196672 43948 10448 S 0.0 0.0 0:05.59 syz-fuzzer
>
> Ah, so it appears to making some progress:
>
> 49652 mingo 20 0 1581740 47600 11344 S 0.0 0.0 0:00.58 syz-manager
> 49661 mingo 20 0 2204868 43720 10448 S 0.0 0.0 0:07.49 syz-fuzzer
>
> 49652 mingo 20 0 1598132 31512 11344 S 0.0 0.0 0:00.61 syz-manager
> 49661 mingo 20 0 2204868 44252 10448 S 0.0 0.0 0:09.09 syz-fuzzer
>
> but only about +1 second runtime added every minute or so. Is that expected?
The main work is done by child syz-executor processes.
syz-manager/syz-fuzzer only guide the process.
You can set "procs" param in config to higher value to increase CPU
utilization. To get more bugs you want to saturate all CPUs to trigger
more unusual thread interleavings.
> There's no progress mark anywhere suggesting that the tool thinks it is going
> fine. You might want to emit periodic (once a minute or so) 'I am still OK!'
> messages or so.
Will do.
Regarding the zombie processes, it may or may not be OK. If they hang
for minutes and you can't kill them, then it is a kernel bug. If they
hang for minutes and you can kill them, then it is either kernel bug
of my bug. If they are recycled eventually, then it is OK. The first
thing I do in such cases is:
$ cat /proc/$PID/task/**/stack
If there is a second unfinished thread hanging on a kernel spinlock or
mutex, then it's definitely bad.
It also helps to enable CONFIG_RCU_STALL_COMMON=y,
CONFIG_DEBUG_ATOMIC_SLEEP=y, CONFIG_WQ_WATCHDOG=y and spinlock/mutex
debugging. These can detect various stalls.
Powered by blists - more mailing lists