1. 20 Nov, 2016 2 commits
  2. 15 Oct, 2016 5 commits
    • jim warner's avatar
      top: tweak some stuff relating to non-displayed fields · f0064ac1
      jim warner authored
      In the commit referenced below, in addition to several
      tweaks to comments, 3 fields were no longer assured of
      being present in the results stacks. However, 2 of the
      3 fields might, in fact, be required even if they were
      not currently being displayed in any of the 4 windows.
      
      The PIDS_CMD is used in two separate 'Inspect' headers
      ('Y' command) and the PIDS_ID_EUID is required if that
      'User Filter' ('u' or 'U' command) was being employed.
      
      That latter field's inclusion will be made conditional
      but the former field must be unconditionally included.
      
      ( for old top, PIDS_CMD would have always been there )
      
      Reference(s):
      commit 4e4debdaSigned-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      f0064ac1
    • jim warner's avatar
      ps: respond to loss of that PIDS_WCHAN_ADDR enumerator · 66c4024d
      jim warner authored
      No longer will ps print nwchan as 'ffffff', '-' or '1'
      since the proc/PID/stat wchan field didn't represent a
      real address anyway. Rather, the field will henceforth
      output a dash ('-'), the ps customary 'not available'.
      
      That man document was also tweaked to better represent
      actual behavior. An asterisk ('*') was never shown for
      threaded tasks and that dash ('-') usually didn't mean
      running tasks (sometimes associated with permissions).
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      66c4024d
    • jim warner's avatar
      library <stat>: remove that PIDS_WCHAN_ADDR enumerator · 91207560
      jim warner authored
      Removing the Item_table 'stat' oldflags for WCHAN_ADDR
      was wrong since that 'stat' field is not a constant 0.
      Rather, it could assume these 3 values: -1, 0, and +1.
      
      I have not been able to pin down a '-1' result, but it
      probably means some sort of permission error (-EPERM).
      
      The '1' or '0' values were supposed to distinguish the
      tasks that were or were not blocked (whether there was
      a wchan address). However, in practice there is little
      correlation between those values and availability of a
      kernel symbol in /proc/$$/wchan (perhaps due to race).
      
      Anyway, the real point is that a 'stat' wchan does not
      now intentionally contain an address. Thus, outputting
      'ffffff', '-' or '1' in programs like ps is senseless.
      
      So this patch just eliminates PIDS_WCHAN_ADDR from our
      item enumerators leaving only the PIDS_WCHAN_NAME guy.
      Now the new library can't be blamed for bad addresses!
      
      Reference(s):
      . removed Item_table 'oldflags'
      commit c4aa6c0a
      . linux removal of wchan addresses
      commit b2f73922d119686323f14fbbe46587f863852328
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      91207560
    • jim warner's avatar
      top: make that 'forest view' just a tad more efficient · f3ec7f00
      jim warner authored
      It makes no sense to begin our tracked nested level at
      '1' then later require a '1' to be subtracted from the
      level as artwork and indentation is added for display.
      
      By beginning such tracked levels at zero, we can avoid
      the need to adjust it & use it directly in a snprintf.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      f3ec7f00
    • jim warner's avatar
  3. 09 Oct, 2016 4 commits
  4. 25 Sep, 2016 2 commits
  5. 21 Sep, 2016 5 commits
    • jim warner's avatar
      library: add priming read at 'new' time <most modules> · 1a2b62c7
      jim warner authored
      A priming read at 'new' time in that <slabinfo> module
      was important so that permission problems are detected
      early. Plus, it also had the potential of making delta
      values valid when 'get' or 'select' were first called.
      
      It is for that latter reason that such a read was also
      incorporated in the <diskstats> module 'new' function.
      No other module, however, employed such priming reads.
      
      This patch just brings those potential benefits to all
      of our other newlib modules with the exception of that
      <pids> guy. That module is, of necessity, sufficiently
      different from those others to justify such exclusion.
      
      Not only are there precious few DELTA enums in <pids>,
      but the costs of a priming read would be much greater.
      
      [ otherwise, these newly added priming reads have no ]
      [ measurable negative impact on performance/timings. ]
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      1a2b62c7
    • jim warner's avatar
      library: summary name now more descriptive, <slabinfo> · 5197fa0a
      jim warner authored
      The <slabinfo> header provides 3 groups of enumerators
      with prefixes of SLABINFO, SLABS & SLABNODE. The first
      is strictly user oriented & isn't supported internally
      by any structure. The other two, however, have structs
      associated with 'em but, unfortunately, 1 is misnamed.
      
      The 'struct slabs_node' is associated with 'nodes' and
      supports the enumerators with the SLABNODE prefix. But
      the 'struct slabs_hist' was associated with 'hist' yet
      supports those enumerators with just the SLABS prefix.
      
      We do not care very much what some structure is called
      but we do care about an identifier used manipulate it.
      
      This patch will trade the 'hist' identifier associated
      with 'struct slabs_hist' for a more congruous 'slabs'.
      
      [ it's awful when the author can't remember what the ]
      [ true meaning of an identifier is after creating it ]
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      5197fa0a
    • jim warner's avatar
      library: improve support of dynamic numa nodes, <stat> · eeeba3e6
      jim warner authored
      If, in fact, numa nodes are dynamic (like that current
      total of on-line cpus) the existing logic was lacking.
      It included an early return before checking the total.
      
      So, this commit ensures that the nodes total is always
      set or updated consistently in only a single function.
      There's no need to set it at the time 'new' is called.
      
      [ and since under our existing code this nodes total ]
      [ could never possibly have been zero, the erroneous ]
      [ test (with the early return) has now been whacked! ]
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      eeeba3e6
    • jim warner's avatar
      top: remove explicit references to NUMA_DISABLE define · a5ec5efc
      jim warner authored
      Since our library is responsible for NUMA support, and
      since the top program already accommodates the lack of
      NUMA data, there's no reason that #define NUMA_DISABLE
      need be explicitly referenced in the top source files.
      
      Ergo, this commit just eliminates all such references.
      Now, top will rely only on procps_stat_reap() results.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      a5ec5efc
    • Jan Rybar's avatar
      NOTES now contain mention of sysctl(8) · b9050f69
      Jan Rybar authored
      b9050f69
  6. 18 Sep, 2016 2 commits
    • jim warner's avatar
      NEWS: updated with most recent copy from master branch · fe3c8d74
      jim warner authored
      This just brings the newlib branch NEWS into line with
      the current version from our master branch since those
      changes have already been incorporated in this branch.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      fe3c8d74
    • jim warner's avatar
      library: finally circumvent libnuma memory leak <stat> · 91d47123
      jim warner authored
      Still unhappy with a minor memory leak associated with
      libnuma, I experimented with omitting the dlclose that
      was issued at module's end. For some reason which will
      remain a mystery, the valgrind leak then went bye-bye.
      
      So this patch just omits one use of dlclose and relies
      on whatever kernel magic is at work to free the memory
      when each process ends. We kept, however, the original
      code (now commented-out) to serve as a future caution.
      
      There remains one potential (but unlikely) dlclose use
      near the original dlopen. But there will be no leak as
      that 'numa_node_of_cpu' will not yet have been called.
      This seems to be the culprit that triggers such leaks.
      
      None of this libnuma shit would likely have come close
      to hitting our fan had the numa developers provided us
      with 'new' and 'unref' functions like our newlib does.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      91d47123
  7. 11 Sep, 2016 2 commits
  8. 10 Sep, 2016 4 commits
    • Olof Sivertsson's avatar
      kill: Fix free() with bad pointer on SIG-prefixed signal-name · 95ed10ff
      Olof Sivertsson authored
      kill -l SIGHUP (or any other signal-name prefixed with "SIG")
      would cause free() to be called with a bad pointer instead of
      a pointer to what was allocated. Fix this and add test-case.
      95ed10ff
    • jim warner's avatar
      pmap: fix printing bug associated with the '-x' option · e02d9f55
      jim warner authored
      Ever since its introduction, the 'x' (extended format)
      option has employed strncmp to parse those smaps keys.
      
      Such an approach worked well as long as those prefixes
      were guaranteed to be unique. But, with the 4.3 kernel
      a new 'SwapPss' field was added to those within smaps.
      
      That triggered a 2nd match for the 'Swap' logic which,
      in turn, resulted in a duplicate output line of zeros.
      
      So this patch just trades strncmp for strcmp, avoiding
      potential future problems when /proc/$$/smaps evolves.
      
      Reference(s):
      . recent bug report
      https://bugzilla.redhat.com/show_bug.cgi?id=1374061
      . linux 4.3 kernel introduces SwapPss
      commit 8334b96221ff0dcbde4873d31eb4d84774ed8ed4
      . original pmap -x option introduction
      commit 380cc1e9Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      e02d9f55
    • jim warner's avatar
      library: normalize stack and history allocation naming · 834ed434
      jim warner authored
      Recent profiling and timings have resulted in improved
      newlib performance. This patch completes that process.
      
      It just normalizes naming conventions employed for all
      allocations involving reaped stacks & history support.
      
      The modules offering a 'reap' function will also offer
      the now standardized corresponding STACKS_INCR define.
      
      The modules which provide dynamic history support will
      now have a separate #define called NEWOLD_INCR used in
      allocations/reallocations. And, while values currently
      are set equal to that STACKS_INCR value, in the future
      some reason for divorcing those two may be discovered.
      
      ----------------------------- for future reference ---
      
      In those modules which contain the STACKS_INCR #define
      it is tempting to specify a large value so as to avoid
      repeated calls to malloc/realloc. However, in doing so
      an extra runtime price will be paid in 'cleanup_stack'
      calls with any iterative programs like top or slabtop.
      
      So, with the current values a balance has been sought.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      834ed434
    • jim warner's avatar
      top: correct comments & code regarding sysinfo_refresh · 793ada6e
      jim warner authored
      This commit just brings some comments plus identifiers
      into agreement with the current newlib implementation.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      793ada6e
  9. 28 Aug, 2016 1 commit
  10. 23 Aug, 2016 7 commits
    • jim warner's avatar
      top: avoid yet more overhead of accessing /proc/status · b53fb7f8
      jim warner authored
      After discovering those terrible costs associated with
      /proc/status vs. /proc/stat, our library changed so as
      to favor the latter if a field could be met by either.
      
      Well, low-and-behold, this top program had chosen some
      item enumerators that needlessly caused 'status' to be
      accessed when 'statm' could be used instead. And while
      top's needs require conversion from pages to KiB, that
      is still far less costly than that damn 'status' file.
      
      [ this was found when comparing newlib top against a ]
      [ 3.2.8 ancient top since the current master top was ]
      [ suffering from the exact same 'status' deficiency. ]
      
      [ and, no way was top-3.2.8 going to beat newlib top ]
      [ by 50% - we'll allow only a 1-10% occasional loss! ]
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      b53fb7f8
    • jim warner's avatar
      library: revert one ancient 'escape_str_utf8' deletion · 3ac040d0
      jim warner authored
      Profiling revealed a large amount of time spent in the
      'escape_str_utf8' function (escape.c) with both of our
      NLS branches (newlib and master). That same result was
      not seen under an ancient top-3.2.8 program & library.
      
      Well, the 3.2.8 result was ultimately explained by the
      absence of a 'setlocale', necessary under NLS support.
      Thus, when that ancient library tested for locale, all
      it got was 'ANSI_...' & assumed 'UTF-8' wasn't active.
      
      But after a hack to that ancient code to place it on a
      par with newlib/master, I still found cost differences
      that led me to revisit an old change referenced below.
      
      It turns out that 'iswprint' costs far more than would
      a call of 'isprint', even with the extra support code.
      So this commit just reverts that five year old change.
      
      Reference(s):
      commit 7b0fc19eSigned-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      3ac040d0
    • jim warner's avatar
      library: miscellaneous additional efficiencies, <pids> · acda6f40
      jim warner authored
      This patch contains the following miscellaneous stuff:
      
      . The pids_stacks_fetch() routine might call for newly
      allocated stacks to be itemized. However, that job was
      already tended to by the pids_stacks_alloc() function.
      
      So, this patch just eliminates a redundant invocation.
      ------------------------------------------------------
      
      . The concept of 'dirty_stacks' has not kept pace with
      the evolving stacks implementation. Originally, stacks
      were considered dirty only if free() of dynamic memory
      was needed before refreshing any single result struct.
      
      Later, with the introduction of the 'extra' item and a
      promise to reset it to zero, 'dirty' was much broader.
      
      So, this patch just treats the dirty flg as others do.
      ------------------------------------------------------
      
      . Lastly, a word or three about performance & timings.
      
      Tuning efforts concentrated on the <pids> API and top.
      And unless an oldlib equivalent to the preceding patch
      is applied (favoring stat vs. status), newlib top will
      often outperform the oldlib version (obviously wrong).
      
      So assuming /proc/stat is preferred in both libraries,
      generally speaking, a cpu and elapsed time increase of
      1-5% was found for this new stacks oriented interface.
      Of course, there's also an increased memory footprint.
      
      There are some occasions, however, when the newlib top
      is at a substantial disadvantage. For example if WCHAN
      or TTY is displayed, such items will be present in all
      newlib reaped stacks (i.e. every process). But old top
      would only incur such overhead with displayable tasks.
      
      Thus, oldlib top could outperform newlib by up to 25%,
      for example, if only fields requiring NO library flags
      were displayed. However, such a scenario is not likely
      since only GID, UID, PID, TGID & WCHAN would be shown.
      In the usual case, that overhead associated with WCHAN
      and/or TTY is overshadowed by other top runtime costs.
      
      All in all a pleasing outcome I deem quite acceptable.
      ------------------------------------------------------
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      acda6f40
    • jim warner's avatar
      library: prefer /proc/stat before /proc/status, <pids> · e9c101ed
      jim warner authored
      Long ago, in a galaxy far away (when top was in charge
      of library FILL flgs) /proc/status was to be preferred
      over /proc/stat if a field could be satisfied by both.
      
      This was done to avoid costly 64-bit math emulation in
      a 32-bit application due to 'unsigned long long' data.
      
      Well it's time to acknowledge the prevalence of 64-bit
      platforms. And in such an environment the cost picture
      has shifted significantly. It now costs 14 times (wow)
      as much to access /proc/status compared to /proc/stat.
      
      In other words, even with '%llu' variables, a sscanf()
      call in stat2proc() beats the pants off that home brew
      gperf based hashing employed by the status2proc() guy.
      In fact, status2proc incurs higher costs than found in
      the most expensive aspect of top's forest view option.
      
      Here's a gprof extract to illustrate the costs. It was
      produced with an rcfile requiring fields from both the
      /proc/stat & /proc/status pseudo files (among others).
      There were 5000 iterations in each of 4 separate gprof
      runs subsequently merged into 1 gmon.sum for analysis.
      
        %      self              self
       time   seconds    calls  us/call  name
       -----  -------  -------  -------  -----------
       28.65     4.10  4689423     0.87  status2proc
       26.14     3.74    40000    93.50  forest_adds
       ...
       01.96     0.28  4689427     0.06  stat2proc
      
      [ since forest_adds is recursive, the calls value is ]
      [ the non-recursive #, its 'call graph' shows totals ]
      
      Anyway, now that such cost is known this patch becomes
      what is euphemistically known as the usual no-brainer.
      
      [ jeeze, was it really this long between profilings? ]
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      e9c101ed
    • jim warner's avatar
      top: minimized default fields requested of our library · 4e4debda
      jim warner authored
      After doing some profiling and timings, then comparing
      newlib top to the existing 3.3.12 version, I concluded
      top should avoid stack results unless actually needed.
      
      Not only will stack depth be kept to minimums, but the
      new library can save some otherwise wasted pathlength.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      4e4debda
    • jim warner's avatar
      library: most function names now more profile friendly · 4fe42d0b
      jim warner authored
      This patch will begin some refinements associated with
      gprof. Initially, functions names have been changed to
      help in identifying potential bottlenecks. This effort
      also included the obscure set, free and sort routines.
      
      Plus the following additional modifications were made:
      
      . the stacks_alloc prologue was generalized plus added
      to a couple of modules where it had not yet propagated
      
      . a couple of the '// end ...' comments were corrected
      
      . some functions have been formally tagged as 'inline'
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      4fe42d0b
    • Christophe Drevet-Droguet's avatar
      b3b6984b
  11. 16 Aug, 2016 3 commits
    • jim warner's avatar
      library: expand fields and break an ABI, <MEMINFO> api · 4f2fe641
      jim warner authored
      The immediately prior commit demonstrated how our APIs
      might be expanded in at some point in the future while
      maintaining binary compatibility in previous programs.
      
      However, since we've yet to release the 1st version of
      our new library, there's no need to violate alphabetic
      ordering just yet. So, this patch restores that order.
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      4f2fe641
    • jim warner's avatar
      library: expand fields yet maintain ABI, <MEMINFO> api · 09e1886c
      jim warner authored
      With the 4.8 kernel, 2 new fields will be added to the
      meminfo pseudo file. This commit, soon to be replaced,
      is intended as an example of how such changes might be
      incorporated plus still maintain binary compatibility.
      
      This actually goes further than is strictly necessary,
      by retaining meminfo_item ordering for 'set' functions
      and the creation of hash table entries. However, there
      is only 1 true requirement, that of Item_table entries
      which must always agree exactly with item enumerators.
      All of the other changes could be done alphabetically.
      
      Ok, so what happens when an old program encounters the
      new expanded meminfo items? Well, if it was thoroughly
      tested against an old library, it won't even see those
      new fields. On the other hand, if it somehow exceeds a
      previous MEMINFO_logical_end, then it will just get an
      extra result structure or two, with no real harm done.
      
      [ this patch is being replace by the very next patch ]
      [ so that our iniitial newlib release can maintain a ]
      [ strict alphabetic ordering in all areas initially! ]
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      09e1886c
    • jim warner's avatar
      misc: use 'VAL' macros to benefit from type validation · 41f7a90a
      jim warner authored
      These 2 programs accessed newlib stacks directly which
      meant incorrect result type specifications couldn't be
      detected using our new result type validation feature.
      
      And, while the usage was correct, to put each on a par
      with all of our other programs, they now rely on those
      newlib offered VAL macros for accessing stack results.
      
      [ the ps and top programs retain direct stack access ]
      [ when assignment to some result struct is necessary ]
      
      [ PIDS_extra is used by top to store the forest view ]
      [ level, while ps uses it for cooked cpu percentages ]
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      41f7a90a
  12. 15 Aug, 2016 2 commits
  13. 10 Aug, 2016 1 commit