来自man renice：
超级用户以外的用户只能改变他们拥有的进程的优先级，并且只能在 0 到 PRIO_MAX (20) [...]
所以，我可以renice向上处理我自己的进程（给它们较低的优先级）但永远不会向下：
$ renice 10 22316
22316 (process ID) old priority 0, new priority 10
$ renice 9 22316
renice: failed to set priority for 22316 (process ID): Permission denied
为什么是这样？我可以理解为什么普通用户不能将 nice 值设置为低于 0，但是为什么既然我可以将优先级降低到 10，我就不能再将它提高到 9？这有什么“安全原因”？我有权启动一个nice值为9的进程，那么为什么我不能将它重新设置为9呢？
编辑：我应该学会向下滚动。原来这被列为一个错误man renice：
BUGS
Non super-users can not increase scheduling priorities of their own
processes, even if they were the ones that decreased the priorities
in the first place.
这更令人困惑。如果他们认为这种行为是一个错误，为什么不改变它呢？该renice命令出现在我认为是 1980 年的 4.0BSD 中。这应该很容易修复，因此一方面他们似乎选择保留它，另一方面他们将其列为错误。
Flu*_*lup 23
这是我所谓的政策原因。这个想法是普通用户不能覆盖特权用户的操作。
假设您是某个巨大共享服务器上的用户。您正在运行巨大的 CPU 占用进程，损害了其他用户的利益。系统管理员renice是你的一些进程，因为他不太喜欢你。操作系统不记得是谁做的renice，但它知道普通用户不能撤销这个操作。通过这种方式，系统管理员可以控制普通用户的进程优先级。
Sté*_*las 23
从 linux 2.6.12 开始，这取决于 RLIMIT_NICE 限制 ( ulimit -e)的值。可以取 0 到 40 之间的值。该限制更多地是对进程优先级的限制（该数字越大，用户可以为进程设置的优先级越高）。
例如，您会注意到 ubuntu 10.04 上的默认值是 20，而 Debian jessie 上的默认值是 0。
的值n对于该限制的装置，如果没有CAP_NICE能力的过程只能增加一个过程的优先级，以达到n，该装置减少nice值下降到的nice值20 - n。因此，对于 0 值，这意味着没有非特权用户可以将 niceness 降低到 20 以下，因此没有非特权用户可以降低 niceness。
值为 20 时，非特权用户可以将 niceness 降低回 0。
管理员可以选择是否允许用户降低其进程优先级，以及通过设置硬限制将其降低到什么级别。
至于为什么管理员可能不希望用户降低他们的进程优先级，请参阅Flup 的回答。