rdma: fixup compile issue
[fio.git] / HOWTO
diff --git a/HOWTO b/HOWTO
index aa06fd5dc40bda09f47f5b4d9f7d7382503f4e4e..8eda99d00bd057a8199107e5508a5fa7d3ebd415 100644 (file)
--- a/HOWTO
+++ b/HOWTO
@@ -799,6 +799,24 @@ cpus_allowed=str Controls the same options as cpumask, but it allows a text
                allows a range of CPUs. Say you wanted a binding to CPUs
                1, 5, and 8-15, you would set cpus_allowed=1,5,8-15.
 
+numa_cpu_nodes=str Set this job running on spcified NUMA nodes' CPUs. The
+               arguments allow comma delimited list of cpu numbers,
+               A-B ranges, or 'all'. Note, to enable numa options support,
+               export the following environment variables,
+                       export EXTFLAGS+=" -DFIO_HAVE_LIBNUMA "
+                       export EXTLIBS+=" -lnuma "
+
+numa_mem_policy=str Set this job's memory policy and corresponding NUMA
+               nodes. Format of the argements:
+                       <mode>[:<nodelist>]
+               `mode' is one of the following memory policy:
+                       default, prefer, bind, interleave, local
+               For `default' and `local' memory policy, no node is
+               needed to be specified.
+               For `prefer', only one node is allowed.
+               For `bind' and `interleave', it allow comma delimited
+               list of numbers, A-B ranges, or 'all'.
+
 startdelay=time        Start this job the specified number of seconds after fio
                has started. Only useful if the job file contains several
                jobs, and you want to delay starting some jobs to a certain
@@ -1062,12 +1080,13 @@ numjobs=int     Create the specified number of clones of this job. May be
                conjunction with new_group.
 
 group_reporting        It may sometimes be interesting to display statistics for
-               groups of jobs as a whole instead of for each individual job. This is
-               especially true if 'numjobs' is used; looking at individual
-               thread/process output quickly becomes unwieldy. To see the final report
-               per-group instead of per-job, use 'group_reporting'. Jobs in a file
-               will be part of the same reporting group, unless if separated by a
-               stonewall, or by using 'new_group'.
+               groups of jobs as a whole instead of for each individual job.
+               This is especially true if 'numjobs' is used; looking at
+               individual thread/process output quickly becomes unwieldy.
+               To see the final report per-group instead of per-job, use
+               'group_reporting'. Jobs in a file will be part of the same
+               reporting group, unless if separated by a stonewall, or by
+               using 'new_group'.
 
 thread         fio defaults to forking jobs, however if this option is
                given, fio will use pthread_create(3) to create threads