1. 07 Feb, 2017 1 commit
  2. 26 Jan, 2017 1 commit
  3. 12 Jan, 2017 1 commit
  4. 08 Jan, 2017 2 commits
  5. 27 Dec, 2016 1 commit
  6. 20 Dec, 2016 2 commits
  7. 25 Nov, 2016 2 commits
  8. 22 Nov, 2016 1 commit
  9. 04 Nov, 2016 1 commit
  10. 01 Nov, 2016 1 commit
  11. 21 Oct, 2016 2 commits
  12. 18 Oct, 2016 1 commit
  13. 11 Oct, 2016 1 commit
  14. 29 Sep, 2016 1 commit
  15. 22 Sep, 2016 1 commit
  16. 20 Sep, 2016 1 commit
  17. 15 Sep, 2016 3 commits
  18. 05 Sep, 2016 1 commit
  19. 21 Aug, 2016 1 commit
  20. 13 Aug, 2016 1 commit
  21. 27 Jul, 2016 1 commit
  22. 21 Jul, 2016 1 commit
  23. 19 Jul, 2016 1 commit
  24. 12 Jul, 2016 2 commits
  25. 23 Jun, 2016 1 commit
  26. 21 Jun, 2016 1 commit
  27. 20 Jun, 2016 2 commits
    • David Edmundson's avatar
      Merge branch 'Plasma/5.7' · c671b462
      David Edmundson authored
      c671b462
    • Rob Wu's avatar
      Include the Slab value in the Cached value · 66eb88fb
      Rob Wu authored
      Before this patch, Cached only counted the page cache.
      With this patch, the slab is also included. This change is visible
      through the APi in "mem/physical/application" and "mem/physical/cached".
      
      Why? For the calculation of used memory (`Appl`), the Slab should not
      be counted as used memory as it is a cache for kernel data structures.
      
      free (from procps) calculates "Used" memory as follows:
      MemTotal - MemFree - (Cached + Slab) - Buffers
      (you can verify this using the numbers from `cat /proc/meminfo`).
      
      This discrepancy in used memory was already noted before, at
      https://mail.kde.org/pipermail/plasma-devel/2008-December/002984.html
      
      > This "Slab" value [1] is not available from the systemmonitor. It usually
      > doesn't grow over 20MB at all anyway. I don't know how important this value
      > is, so is it a feasable solution to simply ignore this and only show used,
      > cache and buffer?
      
      After 10 days of usage, my slab looks like this:
      
      ```
      $ cat /proc/meminfo | grep Slab
      Slab:            2763208 kB
      ```
      
      Clearly, the slab is non-negligible and should be deducted.
      
      The immediate reason for writing this patch is that the "Memory Status"
      plasmoid displayed 4G of "memory usage" even after closing all programs.
      This was confusing, especially when `free -m` showed a much lower value.
      
      From 888675e9a712d626e6ddeeda1372219bd066efdc Mon Sep 17 00:00:00 2001
      From: Rob Wu <rob@robwu.nl>
      Date: Tue, 21 Jun 2016 00:06:51 +0200
      Subject: [PATCH] Include the Slab in the Cached
      
      Before this patch, Cached only counted the page cache.
      With this patch, the slab is also included. This change is visible
      through the APi in "mem/physical/application" and "mem/physical/cached".
      
      Why? For the calculation of used memory (`Appl`), the Slab should not
      be counted as used memory as it is a cache for kernel data structures.
      
      free (from procps) calculates "Used" memory as follows:
      MemTotal - MemFree - (Cached + Slab) - Buffers
      (you can verify this using the numbers from `cat /proc/meminfo`).
      
      This discrepancy in used memory was already noted before, at
      https://mail.kde.org/pipermail/plasma-devel/2008-December/002984.html
      
      > This "Slab" value [1] is not available from the systemmonitor. It usually
      > doesn't grow over 20MB at all anyway. I don't know how important this value
      > is, so is it a feasable solution to simply ignore this and only show used,
      > cache and buffer?
      
      After 10 days of usage, my slab looks like this:
      
      ```
      $ cat /proc/meminfo | grep Slab
      Slab:            2763208 kB
      ```
      
      Clearly, the slab is non-negligible and should be deducted.
      
      The immediate reason for writing this patch is that the "Memory Status"
      plasmoid displayed 4G of "memory usage" even after closing all programs.
      This was confusing, especially when `free -m` showed a much lower value.
      66eb88fb
  28. 19 Jun, 2016 2 commits
  29. 17 Jun, 2016 1 commit
  30. 16 Jun, 2016 2 commits