This just affects how errors are printed. Kleber Sacilotto de Souza
reports:
The error message displayed by the option parser for the 'cpus_allowed'
parameter is misleading.
My system has 4 processors:
$ grep -c processor /proc/cpuinfo
4
If I provide a high number for cpus_allowed, I get the error message:
$ fio --filename=/tmp/foo.fio --cpus_allowed=5 --name=job1
fio: CPU 5 too large (max=4)
fio: failed parsing cpus_allowed=5
If it says "(max=4)", I would expect it to accept the value "4" if I
want to use the last CPU of the system (even though we know that the
CPUs are generally numbered starting with 0), but that's not what
happens:
$ fio --name=global --filename=/tmp/foo.fio --cpus_allowed=4 --name=job1
job1: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
fio-2.1.3
Starting 1 process
fio: pid=24942, err=22/file:backend.c:1192, func=cpu_set_affinity, error=Invalid argument
So for setting the affinity the CPU number really starts from 0, so 3
would be the right value in this case and the following command works as
expected:
Signed-off-by: Jens Axboe <axboe@fb.com>
for (i = 0; i < sizeof(int) * 8; i++) {
if ((1 << i) & *val) {
- if (i > max_cpu) {
+ if (i >= max_cpu) {
log_err("fio: CPU %d too large (max=%ld)\n", i,
- max_cpu);
+ max_cpu - 1);
return 1;
}
dprint(FD_PARSE, "set cpu allowed %d\n", i);