1. 17 Jan, 2022 3 commits
  2. 13 Jan, 2022 4 commits
  3. 07 Jan, 2022 15 commits
  4. 21 Dec, 2021 1 commit
  5. 20 Dec, 2021 2 commits
  6. 16 Dec, 2021 5 commits
  7. 14 Nov, 2021 4 commits
    • Craig Small's avatar
      vmstat: Use KiB instead of pages for paged in/out · dae897b5
      Craig Small authored
      While the kernel calls the fields pgpgin and pgpgout, the units
      here are not pages, but KiB (or 2x 512 sectors).
      
      The comments come from the referenced merged request, this commit fixes
      the "vmstat -s lies" part:
      
      https://elixir.bootlin.com/linux/v5.15-rc7/source/block/blk-core.c#L1057
      has submit_bio() which includes the count_vm_events(PGPGIN, count) but what
      is count? it is usually what bio_sectors() returns.
      
      bio_sectors() is a macro in
      https://elixir.bootlin.com/linux/v5.15-rc7/source/include/linux/bio.h#L49
      that defines that as bio->bi_iter.bi_size >> 9. 2^9 is 512 or the sector
      size. So our count is incremented by the number of 512-byte sectors.
      
      As @dublio
      
       has already pointed out before this result is printed to vmstat,
      it is /= 2 to give the number of kibibytes (as the sectors were 512 bytes,
      we now made the block size 2*512 or 1024). The code even has
      "sectors -> kbytes".
      
      So unless there is something very strange going on, pgpgin and pgpgout in
      /proc/vmstat return kibibytes.
      
      What about pages (which is sort of implied in the name) or blocks (as
      described on the man page)?
      
      Pages can vary, but they are generally 4 KiB so they're out. That also means
      vmstat -s lies :(
      
      Blocks are harder to discount. While these too can vary, they can be 1 KiB;
      they could also be something else (e.g dd its 512, filesystems 4096).
      However, for memory management inside the kernel, there are sectors and
      there are (near userland export) KiB, nothing else. It's probably more
      accurate to say sectors are shifted in and out of block devices and the
      kernel expresses these transfers to userland as KiB by halving the numbers.
      
      What all this means is that using KiB for bi/bo aka pgpgin/pgpgout is more
      accurate than saying blocks or pages.
      Signed-off-by: Craig Small's avatarCraig Small <csmall@dropbear.xyz>
      
      References:
       !64
      dae897b5
    • Weiping Zhang's avatar
      vmstat: use KiB/s for bi/bo instead of blocks/s · 992a37e5
      Weiping Zhang authored and Craig Small's avatar Craig Small committed
      /proc/vmstat provide kbytes to pgpgin and pgpgout instead of blocks,
      correct unit for bi/bo.
      
      References:
       !64
      
      Signed-off-by: default avatarWeiping Zhang <zhangweiping@didichuxing.com>
      Signed-off-by: Craig Small's avatarCraig Small <csmall@dropbear.xyz>
      992a37e5
    • jim warner's avatar
      library: refine support for multiple concurrent access · eafd8e31
      jim warner authored and Craig Small's avatar Craig Small committed
      
      
      Our new library's now well protected against potential
      problems which arise when a multi-threaded application
      opens more than one context within the same API at the
      same time. However, with a single-threaded application
      designed along those same lines, some problems remain.
      
      So, to avoid potential corruption of some data (which
      was classified as local 'static __thread') from those
      single-threaded designs, we'll move several variables
      to the info structure itself and remove the '__thread'
      qualifier. Now they're protected against both designs.
      
      [ we'll not be protected against some multi-threaded ]
      [ application that shares a single context yet calls ]
      [ that interface from separate threads. this is just ]
      [ bad application design & no different than sharing ]
      [ other modifiable global data between such threads! ]
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      eafd8e31
    • jim warner's avatar
      library: this is why we hate those darn tab characters · 126b1447
      jim warner authored and Craig Small's avatar Craig Small committed
      
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      126b1447
  8. 02 Nov, 2021 3 commits
  9. 31 Oct, 2021 1 commit
    • jim warner's avatar
      top: tweak some end-of-job logic when separate threads · ad51fef1
      jim warner authored and Craig Small's avatar Craig Small committed
      The separate threads for background updates were added
      to top in the commit shown below. At that time cleanup
      logic was added to end-of-job processing to cancel any
      active threads and destroy any semaphores then in use.
      
      That seemed like simple good stewardship with an added
      benefit of avoiding potential valgrind 'possibly lost'
      warnings for 320 byte blocks. Those blocks represented
      an initial stack allocation for each of three threads.
      
      All of that worked perfectly if such code was executed
      under the main thread. In other words, if the keyboard
      or a signal directed to any thread was used to trigger
      program end. However, it might not always be the case.
      
      Each of those 'refresh' routines supporting a separate
      thread interacts with a newlib interface. As a result,
      each is required to check the library's return result.
      Should some error be detected, 'error_exit' is called.
      Now we've got big problems with that eoj cleanup code.
      
      One can't 'pthread_cancel' and 'pthread_join' a thread
      from withing that same thread. Thus, when an error was
      returned by the library with threads active, top would
      hang with no possibility of removal short of a reboot.
      
      So, this commit only executes that cancel/join cleanup
      code when we are running under the main thread. Should
      program end be triggered by a library error under some
      sibling thread, all such cleanup will now be bypassed.
      In the latter case, we will rely on documentation that
      says any thread calling exit(3) will end every thread.
      
      [ now, the only time we'll see any valgrind warnings ]
      [ is with a library error, which is the least likely ]
      [ scenario for running valgrind & top to begin with. ]
      
      [ besides, if the valgrind warnings became a problem ]
      [ one could easily add a 'warning-suppression' file. ]
      
      Reference(s):
      . Sep 2021, top introduced threads
      commit 29f0a674
      
      Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
      ad51fef1
  10. 27 Oct, 2021 2 commits