mirror of
https://github.com/AuxXxilium/eudev.git
synced 2025-03-01 00:00:00 +07:00
Repository for eudev development
b38f3aaba1
It is often suggested that users set noop on SSDs and it turns out that udev can do this for users. Setting noop disables the IO priorization and IO reordering logic inside the kernel, but leaves front/back merging in place. This reduction in overhead should increase the number of requests sent to solid state media to the maximum possible,which is said to improve performance on SSDs. Unfortunately, few benchmarks try real world work loads with a clear cache to measure the actual difference. The benchmarks conducted by Daniel Nashed cleared the cache. They favor noop, although the workload seems somewhat unrealistic: http://blog.nashcom.de/nashcomblog.nsf/dx/linux-io-performance-tweek.htm The BFQ developers' benchmarks on SSDs appear to account for both. They show noop as being far better than CFQ and second only to BFQ, which is out of tree: https://lwn.net/Articles/600366/ In addition, I have experienced lockup-like effects on ext4 on an OCZ Vertex 2 SSD with the discard mount option enabled when recursively unlinking a subdirectory path that contains millions of files. The system was useless for hours. Setting noop allowed the unlink to finish in minutes. This is because the reordering from CFQ interleaved the TRIM command with write IOs, effectively putting barriers between them because because TRIM is a non-queued command prior to SATA 3.1. A good default should perform well in general and have the property that poor performance in the worst case scenarios is minimized. The previous examples contradict CFQ's ability to achieve that on solid state media. I believe that we should implement a udev rule to set noop on solid state media by default. It should be said that Milan Broz wrote it first, although there is only one way to write this rule in a manner consistent with the codebase: http://permalink.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/6045 It should be said that this will be a regression for those that rely on the "Block IO Controller" cgroup because it is only supported by CFQ when CONFIG_CFQ_GROUP_IOSCHED=y. My experience as a ZoL developer is that very few users rely on this behavior and consequently, I believe that the benefit from enabling this far outweighs the harm to the few that need it. Those that do need it should be able to disable this rule themselves. Container management software that expects the Block IO Controller to be supported should be modified to enable CFQ explicitly if it does not already do that. This has been tested against both a SATA mechanical drive and a SATA solid state drive. It changes the elevator to noop on the solid state drive, but does not touch it on the mechanical drive. Signed-off-by: Richard Yao <ryao@gentoo.org> |
||
|---|---|---|
| hwdb | ||
| m4 | ||
| man | ||
| rules | ||
| src | ||
| test | ||
| .gitignore | ||
| .travis.yml | ||
| autogen.sh | ||
| configure.ac | ||
| CONTRIBUTING | ||
| COPYING | ||
| LEGACY | ||
| Makefile.am | ||
| NOTES | ||
| README | ||
This git repo is a fork of git://anongit.freedesktop.org/systemd/systemd
with the aim of isolating udev from any particular flavor of system
initialization. In this case, the isolation is from systemd.
This is a project started by Gentoo developers and testing is currently being
done mostly on OpenRC. We welcome contribution from others using a variety of
system initializations to ensure eudev remains system initialization and
distribution neutral.
Homepage: https://wiki.gentoo.org/wiki/Project:Eudev
Tarballs of releases: http://dev.gentoo.org/~blueness/eudev/
Contact: You can email us as a group below.
IRC: Freenode/#gentoo-udev
Committers (alphabetical order by last name):
Luca Barbato (lu_zero) <lu_zero@gentoo.org>
Anthony G. Basile (blueness) <blueness@gentoo.org>
Francisco Izquierdo (klondike) <klondike@gentoo.org>
Ian Stakenvicius (axs) <axs@gentoo.org>
Matthew Thode (prometheanfire) <prometheanfire@gentoo.org>
Tony Vroon (chainsaw) <tony@linx.net>
Richard Yao (ryao) <ryao@gentoo.org>