This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 498461 - I/O scheduler setting via elevator kernel option not picked up by Xen guest
I/O scheduler setting via elevator kernel option not picked up by Xen guest
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Paolo Bonzini
Red Hat Kernel QE team
:
Depends On:
Blocks: 526946
  Show dependency treegraph
 
Reported: 2009-04-30 11:35 EDT by Marc Milgram
Modified: 2014-06-09 09:46 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-30 03:38:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
backport of upstream patches (9.33 KB, patch)
2009-10-05 12:01 EDT, Paolo Bonzini
no flags Details | Diff
patch that just makes blkfront obey elevator=cfq (2.22 KB, patch)
2009-10-12 09:42 EDT, Paolo Bonzini
no flags Details | Diff

  None (edit)
Description Marc Milgram 2009-04-30 11:35:12 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):
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:
Comment 1 Marc Milgram 2009-04-30 11:46:21 EDT
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
Comment 2 Paolo Bonzini 2009-10-05 10:48:25 EDT
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.
Comment 3 Paolo Bonzini 2009-10-05 12:01:16 EDT
Created attachment 363706 [details]
backport of upstream patches

That was just my mistake.  Backport fixed and attached.
Comment 6 Paolo Bonzini 2009-10-12 09:42:42 EDT
Created attachment 364459 [details]
patch that just makes blkfront obey elevator=cfq
Comment 7 Don Zickus 2009-10-21 15:11:37 EDT
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.
Comment 9 Chris Ward 2010-02-11 05:08:36 EST
~~ 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.
Comment 12 errata-xmlrpc 2010-03-30 03:38:29 EDT
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

Note You need to log in before you can comment on or make changes to this bug.