summaryrefslogtreecommitdiff
path: root/library
Commit message (Collapse)AuthorAgeFilesLines
* library: improve the assign results function, pids apiJim Warner2023-05-071-6/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* library: delete a redundant 'items' variable, pids apiJim Warner2023-05-071-11/+9
| | | | | | | | | | | | | | | | 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>
* slabinfo: add comment for cache_size calculationZhao Mengmeng2023-04-252-1/+5
| | | | | | | | | | | | | | 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>
* library: use sd_get_sessions() instead of utmpThorsten Kukuk2023-03-211-3/+20
| | | | | | | 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>
* library: become more tolerant of /proc/cpuinfo formatsJim Warner2023-03-021-11/+17
| | | | | | | | | | | | | | | | | | | | | | | 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>
* misc: tweak the recent copyright changes just a littleJim Warner2023-02-1411-22/+12
| | | | | | | | | | | 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>
* misc: Update the copyrights of filesCraig Small2023-02-0729-99/+190
| | | | | | | | 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>
* tests: Fix type for check_fatal_proc_unmountedCraig Small2022-12-061-1/+1
| | | | | | | | | | | 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>
* library: adapted for absent 'core id' in /proc/cpuinfoJim Warner2022-10-251-10/+23
| | | | | | | | | | | | | 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>
* library: tweak support of p-core/e-core identificationJim Warner2022-10-041-4/+3
| | | | | | | | 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>
* library: provided for cpu p-core/e-core identificationJim Warner2022-09-282-3/+188
| | | | | | | | | | | | | | 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>
* library: address an 'uninitialised value' VALGRIND bugJim Warner2022-09-123-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* misc: Update pc file to new library nameCraig Small2022-08-291-2/+2
|
* library: Rename to libproc2Craig Small2022-08-292-0/+0
| | | | | | | | | | 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>
* build-sys: Relocate library to library/Craig Small2022-08-2941-0/+13581
All the dependent programs needed to have their includes moved too Signed-off-by: Craig Small <csmall@dropbear.xyz>