Some notes on Linux's ionice

February 12, 2013

I was all set to write an entry praising ionice as a perhaps overlooked but rather handy little command, but then I decided to actually measure things on Ubuntu 12.04 to make sure that I wasn't fooling myself. Now you (and I) get a different set of notes.

In theory, ionice allows you to prioritize a command's IO the way that nice(1) theoretically prioritizes its CPU usage. This would be a handy way to allow, say, a big but relatively important compile to grind away in the background without getting in the way of your interactive use of the machine.

(Why yes, I do recompile Firefox from source every so often.)

In practice there are two flies in this ointment. The first is that ionice only works with the CFQ disk scheduler. CFQ is the default for scheduling actual physical disks, but small things like software RAID and LVM do not have disk schedulers at all and as far as I can tell ionice is completely ineffectual on them (for both read and write IO). Unfortunately this renders ionice pointless on my workstation (which is all LVM over software RAID).

The next problem is that even when running directly on a disk, ionice does nothing to de-prioritize asynchronous write IO. This is, well, most of the write IO that most programs will do. Ionice may slow down synchronous writes (I don't have a test program) and it definitely works for reads, but that's it. This might still make a compile not eat your machine (if you're not using LVM or software RAID) since it needs to read things as well as write them, but it now really depends.

What actually doing these tests has show me is that any improvements I thought I was getting from ionice on my workstation was me fooling myself; because I thought ionice would make things nicer, I thought it was (this is a well known effect, of course). In practice ionice is not likely to be of much use to me until it works through (or over) LVM and software RAID. Working on write IO too would be even better.

(My understanding is that write IO is a hard problem in the kernel, but that's another entry.)

Oh well. Not every nifty looking thing actually works out in practice.


Comments on this page:

I'm working from memory (you've been warned), but I think there is a setting that controls the maximum number of segments that can be either in flight, or requested at one time.

/sys/class/block/<dev>/queue/max_segments

I've seen some USB devices have this as low as 27, and my workstation has 128 for my SATA drive.

I believe raising max_segments did improve USB performance. YMMV

Written on 12 February 2013.
« The sinking feeling of discovering a design mistake in your code
The cost of an API mistake in the socket module's fromfd() »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Feb 12 23:28:05 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.