我虽然有些腐烂,但其他方面还好,我的设计是健全的,只要我在运行且没有和 systemd 打起来,系统就会比以往任何时候都运行得顺畅。尽管如此,我的作者抛弃了我,因为他认为他有更重要的事情要做。 请收养我。
此致 ulatencyd
什么是 ulatency
Ulatency 是一个守护进程,用于控制 Linux 内核如何为正在运行的进程分配其 资源。它使用动态 cgroups 为内核提供关于进程的提示和限制。
它强烈支持 lua 脚本语言,用于编写规则和 调度器代码。
它试图修复什么
Linux 调度器在将可用资源分配给 所有进程方面做得相当不错,但在桌面场景下,这可能不是最佳的用户体验。 ulatencyd 监控系统并将正在运行的进程分类到 cgroups 中。 那些因引发大量交换而拖慢系统的失控进程 将被隔离。
CONFIG_SCHED_DESKTOP 不够吗?
有一个针对 2.6.38 的补丁正在处理中,参见 http://thread.gmane.org/gmane.linux.kernel/1050575
我认为这种极简方法在某些情况下是好的,但 无法提供真正的低延迟桌面所需的足够灵活性。 完美的桌面调度需要大量启发式算法,而这些不属于 内核。例如,该补丁无法保护你免受死亡交换、fork 炸弹的影响, 无法检测你实际正在使用哪个进程并为其分配更多 CPU 份额, 无法为诸如 jackd 之类的进程分配实时优先级,等等...
ulatencyd 正是为了解决这些问题而设计的。
构建
构建要求
- libglib2.0-dev
- libdbus-glib-1-dev
- liblua5.1-0-dev | libluajit-5.1-dev
- liblua5.1-posix1(有时称为 luaposix)
- libprocps 3.3.3 用于静态链接(通常位于 libprocps-dev 软件包中) 或共享 libprocps 用于动态链接(需要打补丁以导出 足够的符号)
Cgroups 释放代理(可选):
- dbus-send
文档:
- doxygen
- libmoose-perl
- pandoc
CLI:
- python-dbus
- python2.5+ - python3.2+
GUI:
- python-qt4
- python-qt4-dbus
编译
$ cmake .
$ make DEBUG=1
配置选项(可选):
$ ccmake .
编译故障排除(libprocps)
ulatencyd 需要一些 libprocps 未导出的符号,因此
你必须要么链接到静态 libprocps,要么为该库打补丁以
导出所有必需的符号。
默认情况下,ulatencyd 静态链接到 libprocps。
您可以通过设置 PROCPS_STATIC_LIBRARY 和 PROCPS_STATIC_INCLUDE_DIR
cmake 变量来覆盖静态 libprocps 库和包含
目录的位置。默认情况下,位置将通过
pkg-config 的帮助进行检测。
PROCPS_STATIC_LIBRARY 指定库的完整路径
(即 libprocps.a 文件的路径)
PROCPS_STATIC_INCLUDE_DIR 指定包含
proc/procps.h 头文件的目录。
e.g.:
$ cmake -D PROCPS_STATIC_LIBRARY:FILEPATH=/path/to/libprocps.a
-D PROCPS_STATIC_INCLUDE_DIR:PATH=/path/to/include/dir .
如果您坚持动态链接到共享 libprocps,请更新或修补
libprocps 以导出应用程序所需的所有符号。CMake 将在
配置阶段输出该列表,或者您可以从 CMakeLists.txt 获取
它们。如果您希望您的解决方案具有持久性、
面向未来(在 API 变更的意义上)并正式获得您的
GNU/Linux 发行版的认可,请联系 ulatencyd 作者。
可以通过将
PROCPS_STATIC 设置为 OFF 来启用对共享 libprocps 的动态链接,例如:
$ cmake -D PROCPS_STATIC:BOOL=OFF .
共享 libprocps 和包含目录的位置可以通过
cmake 变量 PROCPS_SHARED_LIBRARY 和 PROCPS_SHARED_INCLUDE_DIR 进行覆盖。
构建文档
$ make docs
安装
$ sudo make install
运行
$ sudo /usr/local/sbin/ulatencyd -v -f /var/log/ulatencyd
链接
- 网站 - https://github.com/poelzi/ulatencyd
- 信息 - https://github.com/poelzi/ulatencyd/wiki
- 常见问题 - https://github.com/poelzi/ulatencyd/wiki/Faq
- 报告错误 - https://github.com/poelzi/ulatencyd/issues
架构

守护进程的核心是用 c 编写的,内嵌了一个 lua 解释器。 大多数规则是用 lua 脚本编写的,因为系统行为的启发式规则 最适合用脚本语言编写。 守护进程将系统信息导出到 lua 脚本中。
实现启发式行为有两种方式:
- 使用超时回调
- 使用过滤器类
超时回调会被调用,直到它返回 True。 过滤器类是首选方式。过滤器在进程上执行, 并可以对进程进行分类。 根据调用的返回值,后续行为可能会有所不同。 返回值由一个标志部分和一个超时部分组成。过滤器 仅在超时秒数后执行。 它也可能导致过滤器不在过滤器的任何子进程上被调用。
进程按树顺序遍历。这意味着进程树被 映射到数据结构中,并从顶部(id = 1,即 init)开始遍历, 然后遍历所有子进程。
更多信息请参阅 wiki。