Re: [RESEND PATCH 0/5] perf core: Support overwrite ring buffer

Ingo Molnar
2016-03-08T18:02:51Z

* Ingo Molnar <mingo@kernel.org> wrote:

>
> * Ingo Molnar <mingo@kernel.org> wrote:
>
> > Things got a lot more lively after that!
> >
> > But most of the overhead seems to come from systemd trying to dump core or
> > something like that:
> >
> > 85872 mingo 20 0 34712 3016 2656 S 4.6 0.0 0:00.14 systemd-coredum
> > 85440 mingo 20 0 34712 3028 2664 S 4.2 0.0 0:00.13 systemd-coredum
> > 85751 mingo 20 0 34712 3076 2716 S 4.2 0.0 0:00.13 systemd-coredum
> > 85840 mingo 20 0 34712 2988 2624 S 4.2 0.0 0:00.13 systemd-coredum
> > 85861 mingo 20 0 34712 3080 2720 S 4.2 0.0 0:00.13 systemd-coredum
> > 85954 mingo 20 0 34712 3028 2664 S 4.2 0.0 0:00.13 systemd-coredum
> >
> > and I have:
> >
> > fomalhaut:~/go/src/github.com/google/syzkaller> ulimit -c
> > 0
> >
> > weird ... Has any of you seen such behavior?
>
> So the workaround for that is to disable systemd trying to log every core dump to
> the system journal (!), via:
>
> echo > /proc/sys/kernel/core_pattern

So with that fixed, I finally started fuzzing for real.

With nproc set to 120 it seems to be chugging along at about 25% system
utilization:

Tasks: 1271 total, 1 running, 1270 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.5 us, 35.3 sy, 0.0 ni, 55.2 id, 0.5 wa, 4.5 hi, 0.0 si, 0.0 st
KiB Mem : 26401230+total, 25401017+free, 1624640 used, 8377496 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 26143329+avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
87593 mingo 20 0 7850436 162284 11672 S 2941 0.1 33:01.83 syz-fuzzer
923 root 20 0 84772 44344 43840 S 22.8 0.0 1:23.86 systemd-journal
1369 root 16 -4 114636 3256 2832 S 15.7 0.0 0:29.03 auditd
1379 root 12 -8 80236 1764 1432 S 8.3 0.0 0:15.79 audispd
878 root 20 0 0 0 0 S 6.9 0.0 0:16.55 jbd2/sda1-8
1381 root 16 -4 52216 3232 2892 S 3.8 0.0 0:07.08 sedispatch

Even that one is not ideal - obviously there's way too much systemd-journal
overhead, but I'm unable to turn the darn thing off ...

with nproc=480 it does not seem to be working very well - it quickly generates:

2016/03/08 18:59:38 local-0: lost connection: exit status 2
2016/03/08 18:59:38 local-0: saving crash 'lost connection' to crash-local-0-1457459978295423413

and then after some time starts to ramp up again. It's mostly idling around.

Thanks,

Ingo