Ami*_*uki 3 process nice procfs
比如我们用ps查看firefox的PRI的值,然后看看procfs中存储的值是多少。
$ ps -o pid,comm,pri,ni 7000
PID COMMAND PRI NI
7000 firefox 19 0
$ cat /proc/7000/stat
7000 (firefox) S 1 6447 6447 0 -1 4194304 3162595 624998 158 10 30467 6903 3360 488 20 0 63 0 464836 9472659456 123045 18446744073709551615 94866409246720 94866409429052 140727418541056 0 0 0 0 4096 33572095 0 0 0 17 2 0 0 342 0 0 94866411526576 94866411528296 94866422095872 140727418542495 140727418542520 140727418542520 140727418544095 0
Run Code Online (Sandbox Code Playgroud)
根据 man proc,我们会在第 18 个值(从 1 开始计数)中找到 PRI 的值,因此在这种情况下 PRI = 20
我想知道为什么ps
命令的输出和 /proc stat 文件中存储的值之间存在这种差异?
嗯,显然该pri
字段正好是 39 减去可见的值/proc/$pid/stat
(所以 39 - 20 = 19)。它也被评论为“不像 UNIX“PRI”那样合法”,因为
Unix98 仅指定高“PRI”是低优先级。
这在那里并不适用。
但!优先级有不少于六种其他输出格式,所有这些格式的原始值要么被否定,要么没有,加上一些常数。挑一个。这是三只nice
价值不同的猫:
$ ps -o pid,rtprio,pri,opri,priority,pri_foo,pri_bar,pri_baz,pri_api,ni,args -Ccat
PID RTPRIO PRI PRI PRI FOO BAR BAZ API NI COMMAND
18418 - 0 99 39 19 40 139 -40 19 cat /dev/zero
18419 - 19 80 20 0 21 120 -21 0 cat /dev/zero
18420 - 39 60 0 -20 1 100 -1 -20 cat /dev/zero
Run Code Online (Sandbox Code Playgroud)
代码中的注释说
Sun 和 SCO 添加了该
-c
行为。Sun 定义了“pri”和“opri”。
所以可能有一些历史原因来修复输出范围以匹配。ps -c
使用pri
这里的值。priority
是内核呈现的原始值。
相关的源代码文件是ps/output.c
:https :
//gitlab.com/procps-ng/procps/blob/master/ps/output.c#L585
另外:https : //superuser.com/questions/286752/unix-ps-l-priority/286761
和/sf/ask/1318054531/
归档时间: |
|
查看次数: |
900 次 |
最近记录: |