You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The prio argument is a value in the range -20 to 20.
So, displayed values are out of range which nice can have.
I've checked htop's source code and can see it does some weird calculations over nice value. Not sure why do we need this code at all, getpriority(2) should return ready to be displayed value.
if (String_eq("intr", kproc->ki_comm) && (kproc->ki_flag & P_SYSTEM)) {
proc->nice = 0; //@etosan: intr kernel process (not thread) has weird nice value
} else if (kproc->ki_pri.pri_class == PRI_TIMESHARE) {
proc->nice = kproc->ki_nice - NZERO;
} else if (PRI_IS_REALTIME(kproc->ki_pri.pri_class)) {
proc->nice = PRIO_MIN - 1 - (PRI_MAX_REALTIME - kproc->ki_pri.pri_level);
} else {
proc->nice = PRIO_MAX + 1 + kproc->ki_pri.pri_level - PRI_MIN_IDLE;
}
I think the values technically make sense: The idle process has the lowest priority (i.e. when nothing else can run) while the kernel processes below it have the highest priorities available to immediately run whenever there's work to do.
Also, why hide them? The wording in the documentation could be refined to include the word "usually" before the range. Furthermore the display of the column could be fixed to avoid breakage with these extreme priorities.
Because it shows some synthetic priority now -- not nice value. And it is even hard to say what the value is. PRI column should be displaying scheduling priority, but they do not match now.
I haven't dug into details, but it looks like Linux uses nice value internally for kernel threads but FreeBSD doesn't, what makes their top's output different: - on FreeBSD and some -20..19 value on Linux.
The wording in the documentation could be refined to include the word "usually" before the range.
Do you mean htop's documentation? In this case nice in htop and nice in UNIX-wide sense will not match, it will matter completely different things. Because nice in UNIX cannot be out of -20..19 range.
My understanding is:
htop tries to display (calculate manually) process' internal priority instead of nice value. It duplicates PRI column in this sense. And it does it only on FreeBSD and only for some processes (kernel threads without nice value).
I'd expect values in top and htop to be equal.
nice is not applicable for FreeBSD kernel threads.
On FreeBSD htop displays weird nice (
NI
column) values for some processes.Here are three rows which looks invalid to me.
As you can see their nice value out of range.
htop's man page says:
getpriority(2) says almost the same
So, displayed values are out of range which nice can have.
I've checked htop's source code and can see it does some weird calculations over nice value. Not sure why do we need this code at all,
getpriority(2)
should return ready to be displayed value.https://github.com/htop-dev/htop/blob/main/freebsd/FreeBSDProcessTable.c#L251
top
from FreeBSD base displays-
in nice column for kernel processes. Shouldhtop
follows the same behavior?The text was updated successfully, but these errors were encountered: