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 gener
Yuri Pankov wrote:
> Mark Millard wrote:
>>
>>
>> On 2018-Dec-24, at 13:49, Yuri Pankov 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 n
Mark Millard wrote:
>
>
> On 2018-Dec-24, at 13:49, Yuri Pankov 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 ord
On 2018-Dec-24, at 13:49, Yuri Pankov 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 e
> No wonder, it doesn't seem to have worked ever (?) as the compare_pid is
> simply not defined in compares list. Try attached patch.
It works on 11-stable without that line being added.
cheers
___
freebsd-current@freebsd.org mailing list
https://list
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 USERNAMETHR PRI NICE SIZERE
>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 USERNAMETHR PRI NICE SIZERES STATEC TIMEWCPU COM
