| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, all the newlib APIs handle the assigning of
results the same. Namely, they loop through the stacks
while checking for the hidden 'logical_end' fencepost.
Along the way, the Item_table was indexed to determine
which 'setsfunc' to call, passing suitable parameters.
The approach was quite robust since by testing against
the unsigned 'logical_end' enumerator this library was
immune from user result corruption. The worst that may
happen was early loop exit with some results unvalued.
However, there was a drawback to the current approach.
For every result structure in every stack, an index to
that Item_table had to be calculated for a 'setsfunc'.
For programs like top or ps that may involve thousands
of Item_table index recalculations for each iteration.
With this commit, in support of assign, we will now do
the needed Item_table calculations just one time under
the 'new' and 'reset' functions. Then, at assign time,
the only overhead is actually invoking the 'setsfunc'.
This makes us even more robust than we were before. No
longer will a corrupted results structure suffer early
assign exit leaving some unvalued. Rather, all results
are properly placed regardless of any user corruption.
[ those other interfaces will remain unchanged since ]
[ the depth of their stacks are modest and since the ]
[ assign guys weren't already passed an info pointer ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ever since this pids api was first introduced in 2015,
there existed both the 'curitems' plus 'maxitems' used
internally. While the reasoning behind such duality is
lost to time, it probably related to top's capacity to
grow/shrink stack size depending on what is displayed.
While top no longer employs a dynamically sized stack,
with the current library logic it makes no difference.
For sometime now the pids guy handles either approach.
So, this commit converts all references to 'maxitems'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of our physical machine shows that the "CACHE SIZE" column
of slabtop output is extremely high, three times of the products
of objs nums and objs size. After some analysis, we found that
the order of slab, which decides "pages per slab", will shrink
when memory pressure is high and normal order allocation failed.
So we think it might help to add these comments to the man help.
Minor fix: add the "memory." back, which is lost after
"aa461df0: docs: Minor manpage fixes"
Signed-off-by: Zhao Mengmeng <zhaomengmeng@kylinos.cn>
|
|
|
|
|
|
|
| |
The utmp format of glibc is not Y2038 safe, not even on 64bit systems.
Query logind/elogind for the number of users if we use libsystemd.
Signed-off-by: Thorsten Kukuk <kukuk@suse.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the issue referenced below, it is now apparent that
not all architectures follow a logical/expected format
for the /proc/cpuinfo file. Specifically, the expected
empty line after each processor entry might be missing
under some architectures for the last processor shown.
[ and a belated review of kernel source confirms it. ]
So this commit makes our stat module a little bit more
tolerant of some potential missing newline characters.
[ along the way, it's also now tolerant of a missing ]
[ cpuinfo file plus more efficient whenever a cpu is ]
[ is not linked to a core or toggled offline/online. ]
Reference(s):
https://gitlab.com/procps-ng/procps/-/issues/272
procps-ng/procps#272
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
|
|
|
| |
This commit just tweaks some recent copyright changes.
Foe example, the six public header files are unique to
this new library and thus are just attributed to Craig
and me. Plus, there were some misnamed file references
as '.c' for '.h' or 'libprocps' instead of 'libproc2'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
| |
The copyrights of the source files were all out of date and were not
the same format. This has been corrected. The source of the authors
was examining the git log for each file.
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
|
|
|
|
|
|
| |
While ps used the correct type for PIDS_VM_RSS the test
did not. For some reason this only appeared to be an issue
for s390x
References:
https://bugs.debian.org/1025495
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A big oops on my part - with a big thanks to Dr. Fink.
[ this version eliminates an extraneous startup call ]
[ to the 'stat_cores_verify' function as superfluous ]
Reference(s):
https://www.freelists.org/post/procps/For-procpsng4001-No-core-id-in-eg-aarch65-or-ppc64le-proccpuinfo
Prototyped by: Dr. Werner Fink <werner@suse.de>
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
| |
Wow, after this we'll eliminate one 'jmp' instruction!
[ plus we can also save a single precious whitespace ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With Intel's 12th generation Alder Lake processors now
providing two distinct types of core, it would be nice
if the library offered some sort of clue to core type.
Well, with this patch it does. We'll have 2 additional
enumerators. One deals with the cpu's core association
and the other provides the type of that core (P or E).
[ now, all we need is for some program to exploit it ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to valgrind and his --track-origins=yes option,
the problem and solution was suggested as shown below.
[ and it was created in that commit referenced below ]
But, after attacking this problem by adding a memset()
call in pids.c, a 2nd valgrind oops, also shown below,
was encountered. The dynamically acquired 'cmd' again!
[ might help to explain why changes appear excessive ]
Reference(s):
. 1st valgrind discovery
==11111== Conditional jump or move depends on uninitialised value(s)
==11111== at 0x13425D: stat2proc (readproc.c:582)
==11111== by 0x137436: look_up_our_self (readproc.c:1613)
==11111== by 0x132196: fatal_proc_unmounted (pids.c:1388)
==11111== by 0x11BA4D: before (top.c:3580)
==11111== by 0x127E10: main (top.c:7173)
==11111== Uninitialised value was created by a stack allocation
==11111== at 0x132165: fatal_proc_unmounted (pids.c:1381)
. Jul, 2022 - fatal_proc_unmounted refactored
commit 52bd019d8ca09ecfec34b5020eb7b8d612c315f8
. 2nd valgrind discovery
==22222== 16 bytes in 1 blocks are definitely lost
==22222== by 0x4A0E60E: strdup (strdup.c:42)
==22222== by 0x133D00: stat2proc (readproc.c:587)
==22222== by 0x136E67: look_up_our_self (readproc.c:1613)
==22222== by 0x131BC7: fatal_proc_unmounted (pids.c:1390)
==22222== by 0x11B7C6: before (top.c:3580)
==22222== by 0x127828: main (top.c:7173)
Signed-off-by: Jim Warner <james.warner@comcast.net>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The newlib library used to be called libproc-2 but the new
name is preferred.
References:
https://www.freelists.org/post/procps/Next-for-newlib,3
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|
|
All the dependent programs needed to have their includes moved too
Signed-off-by: Craig Small <csmall@dropbear.xyz>
|