head -r3418363: top -opid process list order is rather odd (top -Saopid example shown)
Mateusz Guzik
mjguzik at gmail.com
Thu Dec 27 18:36:27 UTC 2018
I suspect this is a side-effect of r340742 ("proc: implement pid hash
locks and an iterator").
Prior to the change exporting code would just iterate allproc, which
will appear sorted for
*most* processes and most importantly kernel ones. Note the allproc
list is most definitely
not sorted in general and a closer look would reveal that.
On 12/25/18, Mark Millard <marklmi at yahoo.com> 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.
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
--
Mateusz Guzik <mjguzik gmail.com>
More information about the freebsd-current
mailing list