Yuri Pankov wrote: > 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. And there's a differential adding both explicit PID sorting, as well as sorting by birth time for those who'd like to have the previous behavior: https://reviews.freebsd.org/D18658
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:19 UTC