Userland depends on ionice idle but default scheduler is "deadline".

Bug #1310402 reported by Zebediah C. McClure
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Triaged
Wishlist
Rohan Garg

Bug Description

Userland depends upon the idle feature of the CFQ scheduler, this can lead to extreme desktop sluggishness with the default deadline scheduler due to IO blocking.

In my case, the KDE baloo indexer was indexing all of my files, and making other desktop processes block. The baloo processes are set to idle IO priority to avoid this problem but this was not being honored.

From the information I have found online and in the ionice man page, the idle priority only is useful with the CFQ scheduler.

KDE Baloo indexer sets it's processes to use "idle" priority

the man-db cronjobs also use idle priority
root@sirius:/etc# grep idle cron.daily/man-db
iosched_idle=
    iosched_idle='--iosched idle'
        --oknodo --chuid man $iosched_idle -- -c \
                      $iosched_idle \

The compiled in default scheduler is "deadline"
root@sirius:/boot# grep DEFAULT_IOSCHED config-3.13.0-24-generic
CONFIG_DEFAULT_IOSCHED="deadline"

from the ionice man page:
Linux supports I/O scheduling priorities and classes since 2.6.13 with the CFQ I/O scheduler.

root@sirius:/boot# uname -a
Linux sirius 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-generic 3.13.0.24.28
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: zmc 2658 F.... pulseaudio
                      zmc 3010 F.... pulseaudio
 /dev/snd/controlC0: zmc 2658 F.... pulseaudio
                      zmc 3010 F.... pulseaudio
CurrentDesktop: KDE
Date: Sun Apr 20 17:23:28 2014
HibernationDevice: RESUME=UUID=dea47071-fda3-4725-a9c5-1f4fc531e6ef
InstallationDate: Installed on 2014-04-18 (2 days ago)
InstallationMedia: Kubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.1)
MachineType: Acer Aspire 7551
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-24-generic root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-24-generic N/A
 linux-backports-modules-3.13.0-24-generic N/A
 linux-firmware 1.127
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/26/2010
dmi.bios.vendor: Phoenix Technologies LTD
dmi.bios.version: V1.15
dmi.board.asset.tag: No Asset Tag
dmi.board.name: Aspire 7551
dmi.board.vendor: Acer
dmi.board.version: V1.15
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: Acer
dmi.chassis.version: V1.15
dmi.modalias: dmi:bvnPhoenixTechnologiesLTD:bvrV1.15:bd10/26/2010:svnAcer:pnAspire7551:pvrV1.15:rvnAcer:rnAspire7551:rvrV1.15:cvnAcer:ct10:cvrV1.15:
dmi.product.name: Aspire 7551
dmi.product.version: V1.15
dmi.sys.vendor: Acer

Revision history for this message
Zebediah C. McClure (zmc) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Are you requesting the default scheduler is changed from deadline to cfq?

Changed in linux (Ubuntu):
importance: Undecided → Wishlist
status: Confirmed → Triaged
tags: added: kernel-da-key
Revision history for this message
Zebediah C. McClure (zmc) wrote :

I'm not certain that changing the default scheduler is the solution, but as it stands, the userland is depending on the CFQ scheduler that is not active.

In the case of anyone with a reletively slow i/o, and processes that expect to run with idle i/o priority, there can be usability problems.

Revision history for this message
Rohan Garg (rohangarg) wrote :

This could be a Kubuntu specific thing ( Where Kubuntu would be the only consumer of CFQ ). Kubuntu could potentially do this via a udev config rule ( something like the one mentioned in http://askubuntu.com/a/473992 )

Changed in linux (Ubuntu):
assignee: nobody → Rohan Garg (rohangarg)
Revision history for this message
Rohan Garg (rohangarg) wrote :

I've worked around this issue in Kubuntu Utopic 14.04 with kubuntu-settings 1:14.10ubuntu3 [1]

It would be awesome if someone from the foundations team could have a look into why Ubuntu can't switch back to CFQ.

[1] https://launchpad.net/ubuntu/+source/kubuntu-settings/1:14.10ubuntu3

Revision history for this message
Michael Mess (michael-michaelmess) wrote :

I have experienced this also on Ubuntu 16.04.7 LTS when I wanted to move 1,5 TB data to an external USB3 disk.

When I started the mv command it performed well until I have noticed that BackupPC and updatedb.mlocate woke up to do plenty of disk activity, slowing down the source disk of the mv command.
Then I used ionice to set the priority of those processes to "idle" and the mv to "rt/4" priority in the hope that the mv will be able to read at maximum speed while the idle processes will have to wait most of the time until the mv process has finished.

But the performance of the mv process didn't increase as expected.

Both, source and target disks are spinning disks, not SSDs.

I would expect that it should be possible to force the linux kernel to process the mv command to be done in maximum speed while other processes should not be able to steal I/O throughput until the mv is done.
I could have killed the other processes, but this is not what I wanted to do for that.

Revision history for this message
Michael Mess (michael-michaelmess) wrote :

Finally I have sent the processes stealing I/O throughput a STOP signal (kill -19),
and voila: The I/O througput of the mv command increased from ~2 Mb/s to ~75 Mb/s.

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.