CFQ may not be the right choice of i/o scheduler for the most common desktop systems

Bug #427210 reported by Sam Davies
102
This bug affects 13 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

Ubuntu currently uses the kernel default i/o scheduler, CFQ. I strongly believe that this is the wrong scheduler to use for the vast majority of likely Ubuntu desktop installs because it causes huge lag in interactive applications under the heavy kind of i/o typically experienced during a file copy or backup operation.

DISCLAIMER: Of course it's always hard to justify these sorts of claims because desktop responsiveness is a notoriously woolly and hard to measure thing, but without at least suggesting some solutions I don't see how we can improve it, hence this bug report.

With that said, I would politely request that the Ubuntu kernel team at least examine the performance, and very importantly, the general desktop responsiveness experienced when using a variety of different i/o schedulers. I also think this could go a long way to solving bug no. 131094 , especially since numerous users in that bug thread have reported significant improvements in responsiveness after changing i/o schedulers.

To reproduce on a standard ubuntu desktop, open (for example) a music player, firefox and/or any other slightly latency sensitive ui applications. Now execute:

sudo dd if=/dev/$ROOTPARTITION of=/dev/zero bs=10M

where $ROOTPARTITION is your root partition eg sda1, hdb2 or whatever. This should simulate the heavy i/o likely to be experienced whilst doing a large file copy/backup or similar. Now go back to normal web browsing/email writing/whatever and observe some truly horrible ui lag and general unresponsiveness.

The current i/o scheduler for a particular partition can be changed on the fly by editing /sys/block/$PARTITION/queue/scheduler. "cat /sys/block/$PARTITION/queue/scheduler" will tell you the current i/o scheduler in use as well as other possible other schedulers that can be used. To change it, you must become root with sudo -s and then "echo $SCHEDULER > /sys/block/$PARTITION/queue/scheduler". The i/o scheduler can be set to a different default globally by appending the elevator=$SCHEDULER option to the grub kernel boot stanza.

Try changing the i/o scheduler for your root partition to "deadline" for example and repeat the test. I observed MASSIVELY improved ui responsiveness during the heavy i/o test on my desktop, and several others who I have discussed this with have seen similar improvements. Now I'm certainly NOT saying "switch to the deadline i/o scheduler", but I do think the ubuntu kernel devs should experiment a bit and see if perhaps the current i/o scheduler is not the best option for desktop responsiveness. After all, a scheduler that copes well with the typical tasks a server has to deal with may not also cope as well with the tasks a desktop has to deal with and vice versa. For Ubuntu Desktop, perceived desktop performance and interactivity should come first, so perhaps the kernel defaults here (which might possibly be tuned more for server-type workloads) may not be the best option.

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
MachineType: System manufacturer P5QL PRO
NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-15-generic 2.6.28-15.49
ProcCmdLine: root=UUID=f9c198f6-df39-49bf-9444-a1ad71d16bf6 ro elevator=deadline quiet splash
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.28-15.49-generic
SourcePackage: linux

Revision history for this message
Sam Davies (seivadmas) wrote :
description: updated
description: updated
Revision history for this message
Bogdan Gribincea (bogdan-gribincea) wrote :

I've been running with the "anticipatory" scheduler for a long time now. The same bug drove me to experiment with the schedulers. Responsiveness under heavy I/O is much better than with CFQ

Every once in a while (when changing kernels) I try CFQ again, without luck. I know CFQ has a few kernel params that we can play with but that's beyond my knowledge unfortunately so I just stuck to using "anticipatory".

Sam Davies (seivadmas)
description: updated
Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

I can confirm the massive increase using the deadline schedule. I'm writing it right now while I'm executing the dd command, and it's only hiccuped once, and not by much at all. It's almost like it's back to where it used to be on responsiveness. 95 percent there.

Revision history for this message
The GuiGuy (linux-finalfiler) wrote :

Wow, that's made a difference when using "deadline"

Many thanks.

Revision history for this message
trumpeteersman (trumpeteersman) wrote :

What kind of storage devices are you guys using? Performance HDDS? Consumer HHDs? SSDs?

Revision history for this message
Paulo J. S. Silva (pjssilva) wrote : Re: [Bug 427210] Re: CFQ may not be the right choice of i/o scheduler for the most common desktop systems

In my case the difference was obvious with a consumer HD (WD AAKS).

Note that the new kernel in 9.10 seems also to be a good improvement.

best,

Paulo

2009/9/11 trumpeteersman <email address hidden>:
> What kind of storage devices are you guys using?  Performance HDDS?
> Consumer HHDs?  SSDs?
>
> --
> CFQ may not be the right choice of i/o scheduler for the most common desktop systems
> https://bugs.launchpad.net/bugs/427210
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Sam Davies (seivadmas) wrote :

I am using cheap consumer HDDs (WD 1.5TB 5400rpm)

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

Generic Seagate 200 GB at 7400 RPM.

Nothing special.

Revision history for this message
Gremlyn1 (gremlyn1) wrote :

I switched to deadline on the fly during a file transfer to USB and noticed an immediate difference in the system responsiveness, though the operations didn't seem to change their data rate, the screen started updating and the system was much more usable. Definitely closer to what I'd expect from a quad-core machine with 4 GB of RAM...

Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

One thing I've noticed since I've changed to deadline is that when I get to the GDM login screen, it's significantly less responsive. Today, it actually took about 15 seconds before I could type in my login and password.

I did do lots of hardware changes, though. Might it have been the computer getting things in order, or has anyone else noticed such a thing happen?

Revision history for this message
Sam Davies (seivadmas) wrote :

For ssds the best scheduler to use is noop, there is no point shuffling around data to optimise for mechanical hard disks when accessing what is essentially a random access disk.

That is another gripe I have with the disk schedulers in ubuntu, for flash drives the scheduler should ALWAYS be noop.

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi guys,

For those of you following along here, you'll likely want to also pay attention to bug 381300.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/381300/comments/17

"It seems the CFQ scheduler has some issues even with SSDs, so I'm gonna experiment with changing the default to DEADLINE in order to facilitate the boot process (where speed is king). You can always change your I/O scheduler setting by writing to /sys/block/*/queue/scheduler."

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-triage
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote :

I installed a fresh copy of Lucid after upgrading since Jaunty. It took me a while to remember why my computer was being so INCREDIBLY sluggish. I was actually starting to get angry.

Bless you, deadline. Linux is so much more enjoyable with you in my pocket.

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-expired
Changed in linux (Ubuntu):
status: Incomplete → Expired
Changed in linux (Ubuntu):
status: Expired → Confirmed
Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

Chauncellor,
   Please don't reopen closed bugs. If you are affected by an issue, please file a new bug.

Thanks!

~JFo

Changed in linux (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
DLHDavidLH (dlhdavidlh-yahoo) wrote :

i think that the default I/O scheduler

 should be change from CFQ to deadline

deadline I/O scheduler is good with both
 SSD (solid-state-drives) and HDD (Hard disk drive)

------------------------------------------------------------------------------------------------------

source:

http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/
http://itezer.com/blog/ubuntu-linux/125-Four_Tweaks_for_Using_Ubuntu_with_SSD.html

Revision history for this message
Peter Grman (peter-grman) wrote :

WOW, this fix worked for me still in Ubuntu 13.10 I have in my laptop combined SSD, HDD, External HDD and USB Sticks (from time to time) and copying files got my system stuck always, but after changing to deadline it seems to be fixed

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.