Kao*_*ome 5 linux process arch-linux priority
我知道在其他操作系统中存在进程优先级，从 -20（大多数优先级）到 19（更少优先级），但 Linux 似乎忽略了它们。
现在我正在后台构建内核（尽管make进程的优先级为 0）并且由于花费了相当长的时间我决定看一些东西。所以我在 VLC 中打开了一个非常苛刻的 H264 视频（Core2 2.6GHz 的 CPU 时间的 30% 左右），结果发现有撕裂、丢帧、视觉伪像（我认为是之前的结果），尽管音频似乎是美好的。
所以我决定改变 VLC using 的优先级renice，具体地看到 PulseAudio-11我决定把它放在同等水平上，所以我做了sudo renice -11 -p VLC_PROC_#。
同样的事情不断发生，所以我继续将它设置为 -20，但我仍然看到视觉伪影。
所以我想知道，为什么 Linux 实际上没有将 -20 进程优先于一些 0 进程并为其提供所需的任何东西？有什么方法可以真正确定 Linux 中的进程优先级吗？
以防万一，我在这里运行 64 位 Arch，XFCE 作为桌面环境。
编辑：内核编译是在/tmp其中执行的，我有tmpfs它的源代码，并且所有内容都已经在 RAM 中。RAM 使用率甚至没有达到 60%，也没有进行分页操作。
上面详述的场景只是一个测试用例，我更感兴趣的是为什么 Linux 是这样执行的，以及是否有任何方法可以获得真正的优先级。
renice确实会影响进程的优先级。但正如您所经历的，仅仅因为进程具有更高的优先级并不意味着它将拥有它需要的所有资源。更高的优先级只会让进程有更大的机会获取资源。
renice只影响 CPU 时间。因此，只有当两个或更多进程争用 CPU 时间时，它才会产生影响。如果限制因素不是 CPU 时间而是 I/O 带宽，则 nice 值没有影响。也许在您的情况下，编译使用了大量磁盘带宽，而 vlc 无法足够快地从磁盘读取数据。尝试ionice替代或补充nice。
如果您经常这样做，如果视频和编辑在不同的磁盘上，您将获得更好的结果。此外，如果您将视频预加载到磁盘缓存中（cat /path/to/video.file >/dev/null或tail -c +456m | head -c 123m /path/to/video.file >/dev/null从偏移量 456MB 开始读取 123MB），您可能会获得更好的结果——但除非您有大量 RAM，否则编译可能会收回缓存空间。如果您想确保视频在内存中，请制作一个 ramdisk 并将视频复制到其中。
当您尝试调整用户体验时，进程优先级并不是唯一发挥作用的因素。编译内核是一件 I/O 繁重的事情 - 大量从小文件中读取/写入，这可能会大大拉伸文件系统（这就是为什么它有时本身被用作基准测试的原因） ，特别是在多处理器机器上。如果您有足够的 RAM，我建议您尝试在 tmpfs 中编译内核 - 至少部分地：要么将源代码树放在那里（这将有效地将其预取到缓存中），要么使用以下命令将输出发送到那里
make O=/dev/shm ...
或者在您决定将实例安装得tmpfs足够大以容纳内核对象文件的任何地方 - 这很容易在千兆字节范围内）。
除此之外，您还可以检查 VLC 是否具有缓存功能（我猜测它具有，例如 MPlayer 有选项-cache），您可以使用该功能请求在内部缓存数据。然后，它不需要在需要时获取数据，而是在数据可用时获取数据。
另一件事是显示是通过 X 服务器完成的 - 它的优先级也必须提高（请参阅 Wumpus Q. Wumbley 在该问题下的评论）。
另外两个选项是使用 cgroups 和/或 RT 调度程序（第一个选项请参见例如使用 cgroups 控制应用程序的优先级，对于后者请参见例如Gentoo 指令）。
最后一件事是，您可能想通过关闭不必要的服务来稍微优化您的系统。就我个人而言，我认为 PulseAudio 是首选。
然而，您所描述的听起来更像是发生了一些高优先级 I/O - 我的猜测是，您经历了一些繁重的交换 - 您确定您的 tmpfs 没有被迫被换出吗？那样的话，恐怕至少iorenice不会有太大帮助。