Red Hat Bugzilla – Bug 498461
I/O scheduler setting via elevator kernel option not picked up by Xen guest
Last modified: 2014-06-09 09:46:26 EDT
Description of problem:
Adding kernel option "elevator=cfq" to /boot/grub/grub.conf entry of Xen guest is not picked up (applied) by guest on reboot. Guest defaults to "noop" scheduler on reboot. Customer need cfq as the scheduler as he is running RAID5 as the backend which gives 2x performance for io with cfq. See more details at http://people.redhat.com/sputhenp/performance.txt
Currently the scheduler for guest is hardcoded to noop for the reason explained at http://www.nabble.com/Default-disk-I-O-scheduler-in-linux-guest-td21841023.html
elevator=scheduler picks up the right scheduler on Dom0, and fully virtualized geusts. The problem is only with paravirtualized guests.
Looking at the code, this has been set in xlvbd_init_blk_queue()
219 elevator_init(rq, "noop");
Customer has currently worked around this by putting "echo cfq > /sys/block/xvda/queue/scheduler" in /etc/rc.local.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add kernel option "elevator=cfq" to /boot/grub/grub.conf entry of Xen guest
2. Reboot guest
3. Examine the contents of /sys/block/xvda/queue/scheduler
Scheduler is set to noop
Scheduler is set to cfq
Changes were committed to the upstream kernel in the 2.6.28 time frame which replace the call to elevator_init("noop") with a call to queue_flag_set_unlocked(QUEUE_FLAG_VIRT, rq).
These changes are based on a new queue flag, QUEUE_FLAG_NONROT - which changes the behaviour of elevator schedulers for non-rotational devices.
It is not clear if these changes would fix the guest performance issue, or not.
Here is the set of changes to implement the QUEUE_FLAG_VIRT flag:
68aee07f9bad2c830a898cf6d6bfc11ea24efc40 Release old elevator on change elevator
66d352e1e410dcea22fecb9fa9ec09dd23a62e1c xen-blkfront: set queue paravirt flag
Eliminates setting noop elevator
7d116b626b843c66b17630a62d696e044d049bfc virtio_blk: set queue paravirt flag
88e740f1654bf28565edd528a060695c1f2b5ad7 block: add queue flag for paravirt frontend drivers
The following changes are necessary for dependencies:
a68bbddba486020c9c74825ce90c4c1ec463e0e8 block: add queue flag for SSD/non-rotational devices
We don't want to idle in AS/CFQ if the device doesn't have a seek
penalty. So add a QUEUE_FLAG_NONROT to indicate a non-rotational
device, low level drivers should set this flag upon discovery of
an SSD or similar device type.
1308835ffffe6d61ad1f48c5c381c9cc47f683ec block: export SSD/non-rotational queue flag through sysfs
The following changes enable nonrot in other drivers, but are probably not necessary for this BZ:
8bff7c6b0f63c7ee9c5e3a076338d74125b8debb libata: set queue SSD flag for SSD devices
8dddfe192632361b62eee9c8320bc9feff57898b mmc_block: tell block layer there is no seek penalty
31dcfab0ae6eb0340d456931df4d478e17efc65d nbd: tell the block layer that it is not a rotational device
c77380d4534c65cc9865a6b4efea44be4d039207 ide-disk: set non-rotational queue flag for SSD and CF devices
655772cc79c94ebf282e1df4d3c3375f05a565ae ide: can't use SSD/non-rotational queue flag for all CFA devices
20137a490f397d9c01fc9fadd83a8d198bda4477 swapfile: swapon randomize if nonrot
644b2d99b7a8677a56909a7b1fde31677eba4471 block: enabling plugging on SSD devices that don't do queuing
I tried backporting the patches and the flag does not work on RHEL5's kernel with the cfs scheduler:
1) a simple backport doesn't boot, locking soon after "Creating root device".
2) I tried backporting everything except setting the flag (thus having the support but not using it by default) and the kernel boots. However, if I do
echo 0 > /sys/block/xvda/rotational
it locks about two seconds after du / starts. I'll now try anticipatory.
Created attachment 363706 [details]
backport of upstream patches
That was just my mistake. Backport fixed and attached.
Created attachment 364459 [details]
patch that just makes blkfront obey elevator=cfq
You can download this test kernel from http://people.redhat.com/dzickus/el5
Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so. However feel free
to provide a comment indicating that this fix has been verified.
~~ Attention Customers and Partners - RHEL 5.5 Beta is now available on RHN ~~
RHEL 5.5 Beta has been released! There should be a fix present in this
release that addresses your request. Please test and report back results
here, by March 3rd 2010 (2010-03-03) or sooner.
Upon successful verification of this request, post your results and update
the Verified field in Bugzilla with the appropriate value.
If you encounter any issues while testing, please describe them and set
this bug into NEED_INFO. If you encounter new defects or have additional
patch(es) to request for inclusion, please clone this bug per each request
and escalate through your support representative.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.