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): kernel-2.6.18-128.el5 How reproducible: Every time. 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 Actual results: Scheduler is set to noop Expected results: Scheduler is set to cfq Additional info:
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 du / 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
in kernel-2.6.18-170.el5 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. http://rhn.redhat.com/errata/RHSA-2010-0178.html