[LAU] IO scheduler for realtime audio?

[Jaromír Mikeš]

2011/1/9 Robin Gareus <robin at gareus.org>:

> As for SSD disks with ext4 I don't know. I've not yet analyzed this
> combination, but my gut-feeling is to use the deadline scheduler

Just installed my system and deadline scheduler seems to be fine ... not tested

> Some details that may or may not come in handy:
>
> "best for audio" could mean:
>  - max thoughput : record/play lots of tracks simultaneously
>  - low latency:  lots of random seeks, many small files.
>  - low CPU usage of the scheduler: mostly negligible but can become
> important with large fifo_queue for the deadline sched.

I think it should mean something like this.

> They're contradicting each other.
>
> 'noop' and 'deadline' yield better performance for SSDs; but noop is not
> really suitable if you want to do concurrent/multi-threaded disk access
> (noop will block when accessing large files).

Actually my very first choice boiled down to noop, deadline and bfs

BTW:Why not bfs?

> With the deadline scheduler you should also increase the number of seeks
> (they're cheap on SSDs) and thereby reduce latency with
>  echo 1 > /sys/block/DEVICE/queue/iosched/fifo_batch
> (a higher value will reduce seeks but also increases latency.)

I set it as you recommend.

> You may want to run some tests. a simple read-test:
>  `hdparm -t DEVICE`

Just if you are interested:
$ sudo hdparm -t /dev/sda3

/dev/sda3:
 Timing buffered disk reads: 630 MB in  3.00 seconds = 209.99 MB/sec

> Timing a kernel compilation is another good test.
>
> Query and change the scheduler on the fly:
>  cat /sys/block/DEVICE/queue/scheduler
>  echo SCHEDULER > /sys/block/DEVICE/queue/scheduler
> where DEVICE is e.g. 'sda' and SCHEDULER is one of
>  'noop' 'anticipatory' 'deadline' 'cfq' 'bfq'
>
> and you can make the change permanent by
>  a) recompiling the kernel
> or
>  b) use 'elevator=SCHEDULER' boot-flag
> or
>  c) set it via /etc/sysctl.conf

I set it by adding this line to /etc/rc.local file
echo deadline > /sys/block/sda/queue/scheduler

And I also added these lines there
sysctl -w vm.swappiness=1 # Strongly discourage swapping
sysctl -w vm.vfs_cache_pressure=50 # Don't shrink the inode cache aggressively

And this entry to /etc/fstab
tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0

Here I found a lot of interesting info:
http://forums.fedoraforum.org/showthread.php?t=215109
http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/


> There's a few more things you can tweak in
>  /sys/block/DEVICE/queue/iosched/
> but those depends on the scheduler.
>
> http://wiki.linuxquestions.org/wiki/IOSched has an overview of the I/O
> schedulers (excl. bfq) and lists the important tweakable parameters.
> /usr/src/linux/Documentation/block has the details.

nice link ... thank you

> A general good advice is to mount SSDs with the
> 'noatime' mount-option to reduce writes to the device and prolong the
> lifetime. For ext4 also use the 'discard' option which enables TRIM:
> http://en.wikipedia.org/wiki/TRIM

I also used 'nodiratime' option

> There's even more tweaks: for instance you can disable write-back caching:
>  hdparm -W0 DEVICE
> It's usually enabled by default, but the architecture of an SSD often
> results in poorer performance with it.
>
>
> Most of this info comes from a brainstom session (collected from various
> sites and mailing-lists) in order to make a dedicated .deb package which
> automatically does this changes for 64studio, but things are moving slowly.
>
> Also note that ext4 and SSD-block drivers have been updated and improved
> since 2.6.33. You may see some improvement with newer kernels.

Yes I am looking forward 2.6.37-rt ;)

Just for completeness partitions allingment should be probably
mention, but i am still not understand it properly.
http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/

regards

mira