Roll src/third_party/afl/src/ 2.14b..2.30b (16 versions).

third_party/afl/src/docs/perf_tips.txt

 =================================
 Tips for performance optimization
 =================================
 
   This file provides tips for troubleshooting slow or wasteful fuzzing jobs.
   See README for the general instruction manual.
 
 1) Keep your test cases small
 -----------------------------
 
@@ skipping 126 matching lines @@
 For programs that are nominally very fast, but get sluggish for some inputs,
 you can also try setting -t values that are more punishing than what afl-fuzz
 dares to use on its own. On fast and idle machines, going down to -t 5 may be
 a viable plan.
 
 The -m parameter is worth looking at, too. Some programs can end up spending
 a fair amount of time allocating and initializing megabytes of memory when
 presented with pathological inputs. Low -m values can make them give up sooner
 and not waste CPU time.
 
-8) Set CPU core affinity for AFL
---------------------------------
-
-Making sure that the fuzzer always runs on the same (idle) CPU core can offer
-a significant speed bump and reduce scheduler jitter. The benefits can be even
-more striking on true multiprocessor systems.
-
-On Linux, you can assign the fuzzer to a specific core by first running
-afl-gotcpu to see which cores are idle, and then specifying the ID of a
-preferred core via -Z, like so:
-
-  $ ./afl-fuzz -Z core_id [...other parameters...]
-
-Note that this parameter needs to be used with care; accidentally forcing
-multiple fuzzers to share the same core may result in performance that is
-worse than what you would get without -Z.
-
-(It is also possible to specify two comma-delimited values for -Z, in which
-case, the fuzzer will run on one designated core, and the target binary will
-be banished to another. This can sometimes offer minor benefits, but isn't
-recommended for general use.)
-
-9) Check OS configuration
+8) Check OS configuration
 -------------------------
 
 There are several OS-level factors that may affect fuzzing speed:
 
   - High system load. Use idle machines where possible. Kill any non-essential
     CPU hogs (idle browser windows, media players, complex screensavers, etc).
 
   - Network filesystems, either used for fuzzer input / output, or accessed by
     the fuzzed binary to read configuration files (pay special attention to the
     home directory - many programs search it for dot-files).
@@ skipping 13 matching lines @@
     one target to another, but on Linux, you may want to make sure that the
     following options are set:
 
     echo 1 >/proc/sys/kernel/sched_child_runs_first
     echo 1 >/proc/sys/kernel/sched_autogroup_enabled
 
     Setting a different scheduling policy for the fuzzer process - say
     SCHED_RR - can usually speed things up, too, but needs to be done with
     care.
 
-10) If all other options fail, use -d
--------------------------------------
+9) If all other options fail, use -d
+------------------------------------
 
 For programs that are genuinely slow, in cases where you really can't escape
 using huge input files, or when you simply want to get quick and dirty results
 early on, you can always resort to the -d mode.
 
 The mode causes afl-fuzz to skip all the deterministic fuzzing steps, which
 makes output a lot less neat and makes the testing a bit less in-depth, but
 it will give you an experience more familiar from other fuzzing tools.