diff options
| author | Dan Williams <dan.j.williams@intel.com> | 2011-07-23 20:44:25 +0200 |
|---|---|---|
| committer | Jens Axboe <jaxboe@fusionio.com> | 2011-07-23 20:44:25 +0200 |
| commit | 5757a6d76cdf6dda2a492c09b985c015e86779b1 (patch) | |
| tree | 6356a6353639eb473dd917a1b2062f9e7e20de22 /Documentation | |
| parent | ef3230880abd36553ab442363d3c9a0661f00769 (diff) | |
| download | linux-exynos-5757a6d76cdf6dda2a492c09b985c015e86779b1.tar.gz linux-exynos-5757a6d76cdf6dda2a492c09b985c015e86779b1.tar.bz2 linux-exynos-5757a6d76cdf6dda2a492c09b985c015e86779b1.zip | |
block: strict rq_affinity
Some systems benefit from completions always being steered to the strict
requester cpu rather than the looser "per-socket" steering that
blk_cpu_to_group() attempts by default. This is because the first
CPU in the group mask ends up being completely overloaded with work,
while the others (including the original submitter) has power left
to spare.
Allow the strict mode to be set by writing '2' to the sysfs control
file. This is identical to the scheme used for the nomerges file,
where '2' is a more aggressive setting than just being turned on.
echo 2 > /sys/block/<bdev>/queue/rq_affinity
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Roland Dreier <roland@purestorage.com>
Tested-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/block/queue-sysfs.txt | 10 |
1 files changed, 7 insertions, 3 deletions
diff --git a/Documentation/block/queue-sysfs.txt b/Documentation/block/queue-sysfs.txt index f65274081c8d..d8147b336c35 100644 --- a/Documentation/block/queue-sysfs.txt +++ b/Documentation/block/queue-sysfs.txt @@ -45,9 +45,13 @@ device. rq_affinity (RW) ---------------- -If this option is enabled, the block layer will migrate request completions -to the CPU that originally submitted the request. For some workloads -this provides a significant reduction in CPU cycles due to caching effects. +If this option is '1', the block layer will migrate request completions to the +cpu "group" that originally submitted the request. For some workloads this +provides a significant reduction in CPU cycles due to caching effects. + +For storage configurations that need to maximize distribution of completion +processing setting this option to '2' forces the completion to run on the +requesting cpu (bypassing the "group" aggregation logic). scheduler (RW) -------------- |