Mark Millard wrote: > > > On 2018-Dec-24, at 13:49, Yuri Pankov <yuripv at yuripv.net> wrote: > >> Mark Millard wrote: >>> From my from=source head -r3418363 context, top with -opid does not >>> seem to sort in a coherent order, not time of process creation order >>> (either direction) and not in just-PID numeric order (either >>> direction). For example: >>> >>> PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU >>> COMMAND >>> 0 root 24 -16 - 0 368K swapin 1 0:00 0.00% >>> [kernel] >>> 16 root 1 -16 - 0 16K - 3 0:00 0.00% >>> [soaiod2] >>> 752 root 1 20 0 18M 18M select 1 0:07 0.01% >>> /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -g >>> 800 root 1 20 0 11M 908K nanslp 1 0:01 0.00% >>> /usr/sbin/cron -s >>> 1 root 1 20 0 9900K 132K wait 3 0:00 0.00% [init] >>> 17 root 1 -16 - 0 16K - 0 0:00 0.00% >>> [soaiod3] >>> 2 root 1 -16 - 0 16K crypto 0 0:00 0.00% >>> [crypto] >>> 18 root 1 -16 - 0 16K - 0 0:00 0.00% >>> [soaiod4] >>> 850 root 1 20 0 13M 2756K wait 3 0:00 0.00% login >>> [pam] (login) >>> 3 root 1 -16 - 0 16K crypto 0 0:00 0.00% >>> [crypto returns 0] >>> 19 root 1 -16 - 0 16K mmcsd 0 0:25 0.00% >>> [mmcsd0: mmc/sd card] >>> 643 root 1 20 0 11M 1124K select 2 0:01 0.00% >>> /usr/sbin/syslogd -s >>> 4 root 1 -16 - 0 16K crypto 0 0:00 0.00% >>> [crypto returns 1] >>> 20 root 1 -16 - 0 16K mmcsd 0 0:00 0.00% >>> [mmcsd0boot0: mmc/sd] >>> 5 root 1 -16 - 0 16K crypto 0 0:00 0.00% >>> [crypto returns 2] >>> 21 root 1 -16 - 0 16K mmcsd 0 0:00 0.00% >>> [mmcsd0boot1: mmc/sd] >>> 6 root 1 -16 - 0 16K crypto 0 0:00 0.00% >>> [crypto returns 3] >>> 22 root 3 -16 - 0 48K psleep 3 0:12 0.00% >>> [pagedaemon] >>> 5270 root 1 20 0 14M 3780K CPU2 2 0:00 0.14% top >>> -Saopid >>> 662 root 1 20 0 11M 680K select 0 0:00 0.00% >>> /usr/sbin/rpcbind >>> 7 root 2 -16 - 0 32K - 0 0:00 0.00% [cam] >>> 23 root 1 -16 - 0 16K psleep 2 0:00 0.00% >>> [vmdaemon] >>> 5255 root 1 20 0 12M 3092K wait 0 0:00 0.00% -sh >>> (sh) >>> 8 root 1 -16 - 0 16K waitin 0 0:00 0.00% >>> [sctp_iterator] >>> 24 root 3 -16 - 0 48K qsleep 3 0:12 0.01% >>> [bufdaemon] >>> 712 root 1 52 0 12M 616K select 0 0:00 0.00% >>> /usr/sbin/mountd -r >>> 9 root 1 -16 - 0 16K - 1 0:04 0.00% >>> [rand_harvestq] >>> 25 root 1 20 - 0 16K vlruwt 0 0:04 0.00% >>> [vnlru] >>> 10 root 1 -16 - 0 16K audit_ 0 0:00 0.00% >>> [audit] >>> 26 root 1 16 - 0 16K syncer 0 1:45 0.00% >>> [syncer] >>> 714 root 1 52 0 12M 728K select 3 0:00 0.00% nfsd: >>> master (nfsd) >>> 11 root 4 155 ki31 0 64K CPU0 0 144.6H 397.09% [idle] >>> 235 root 1 20 0 11M 564K select 3 0:00 0.00% >>> dhclient: system.syslog (dhclient) >>> 715 root 32 52 0 11M 1120K rpcsvc 3 0:00 0.00% nfsd: >>> server (nfsd) >>> 12 root 18 -52 - 0 288K WAIT 2 2:29 1.43% [intr] >>> 412 root 1 20 0 10M 72K select 2 0:00 0.00% >>> /sbin/devd >>> 796 root 1 52 0 20M 672K select 0 0:00 0.00% >>> /usr/sbin/sshd >>> 13 root 3 -8 - 0 48K - 1 0:11 0.00% [geom] >>> 14 root 20 -68 - 0 320K - 0 0:02 0.00% [usb] >>> 238 root 1 52 0 12M 416K select 1 0:00 0.00% >>> dhclient: awg0 [priv] (dhclient) >>> 15 root 1 -16 - 0 16K - 0 0:00 0.00% >>> [soaiod1] >>> 239 _dhcp 1 20 0 12M 484K select 1 0:00 0.00% >>> dhclient: awg0 (dhclient) >>> >>> (Basically the Pine64+ 2GB [aarch64] above was idle after boot other than >>> some runs of top.) >>> >>> I see this oddity across architectures, for example amd64, powerpc64, >>> aarch64, armv7. >> >> No wonder, it doesn't seem to have worked ever (?) as the compare_pid is >> simply not defined in compares list. Try attached patch. >> <top.diff> > > I'm a long term top user and it used to work. For example, when I was running > head -r340287 it worked as I remember. (I recreated such a vintage recently > for a test of something else. The -opid ordering was coherent as I remember, > unlike the above.) > > It historically seemed to track the time order of process creation, even > around the PID > number wrapping around. (So not a strict PID sort, at least for the PID > shown.) This > was handy for monitoring buildworld buidkernel and port builds (all parallel). > > I'll probably try the patch when I have a chance, even if it does strict PID > number > order. Thanks.
OK, so top never did sort for '-opid' by itself, and rather relied on the process list to be sorted by birth time internally (as returned by kvm_getprocs()) and it doesn't seem to be really sorting by PID, more so when PID numbers wrap. Quick bisect shows that this behavior was changed by r340742 ("proc: implement pid hash locks and an iterator"), so I guess we now just need to implement real sorting by PID. I have attached another patch version adding pid comparison function done like the other ones.
diff --git a/usr.bin/top/machine.c b/usr.bin/top/machine.c index 374c9da0edf4..8c0db365f8a5 100644 --- a/usr.bin/top/machine.c +++ b/usr.bin/top/machine.c @@ -1276,6 +1276,12 @@ static int sorted_state[] = { return (diff > 0 ? 1 : -1); \ } while (0) +#define ORDERKEY_PID(a, b) do { \ + int diff = (int)b->ki_pid - (int)a->ki_pid; \ + if (diff != 0) \ + return (diff > 0 ? 1 : -1); \ +} while (0) + /* compare_cpu - the comparison function for sorting by cpu percentage */ static int @@ -1420,6 +1426,24 @@ compare_swap(const void *arg1, const void *arg2) return (0); } +/* compare_processid - the comparison function for sorting by pid */ +static int +compare_processid(const void *arg1, const void *arg2) +{ + const struct kinfo_proc *p1 = *(const struct kinfo_proc * const *)arg1; + const struct kinfo_proc *p2 = *(const struct kinfo_proc * const *)arg2; + + ORDERKEY_PID(p1, p2); + ORDERKEY_PCTCPU(p1, p2); + ORDERKEY_CPTICKS(p1, p2); + ORDERKEY_STATE(p1, p2); + ORDERKEY_PRIO(p1, p2); + ORDERKEY_RSSIZE(p1, p2); + ORDERKEY_MEM(p1, p2); + + return (0); +} + /* assorted comparison functions for sorting by i/o */ static int @@ -1511,7 +1535,7 @@ int (*compares[])(const void *arg1, const void *arg2) = { compare_ivcsw, compare_jid, compare_swap, - NULL + compare_processid };
signature.asc
Description: OpenPGP digital signature