2011/1/9 Robin Gareus <robin@xxxxxxxxxx>: > 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
