Re: cpus_allowed per thread behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2014-02-26 15:54, Elliott, Robert (Server Storage) wrote:
fio seems to assign the same cpus_allowed/cpumask value to all threads.
> I think this allows the OS to move the threads around those CPUs.

Correct. As long as the number of cpus in the mask is equal to (or larger than) the number of jobs within that group, the OS is free to place them wherever it wants. In practice, unless the CPU scheduling is horribly broken, they tend to "stick" for most intents and purposes.

In comparison, iometer assigns its worker threads to specific CPUs
> within the cpumask in round-robin manner.  Would that be worth adding
> to fio, perhaps with an option like cpus_allowed_policy=roundrobin?

Sure, we could add that feature. You can get the same setup now, if you "unroll" the job section, but that might not always be practical. How about cpus_allowed_policy, with 'shared' being the existing (and default) behavior and 'split' being each thread grabbing one of the CPUs?

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe fio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Linux SCSI]     [Linux IDE]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux