Announcement

Collapse
No announcement yet.

Linux "PSI" Patches Report Stall/Pressure Information For CPU / Memory / Storage

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux "PSI" Patches Report Stall/Pressure Information For CPU / Memory / Storage

    Phoronix: Linux "PSI" Patches Report Stall/Pressure Information For CPU / Memory / Storage

    One of the interesting patch series in the works is the "PSI" work by Johannes Weiner of Facebook...

    http://www.phoronix.com/scan.php?pag...tches-Interest

  • torsionbar28
    replied
    Originally posted by Tomin View Post
    Why are you showing me this cruel picture of a poor slaughtered memory module?!
    Clearly this module's civil rights have been violated, where's Al Sharpton and his rabble rousing?? We must sue!

    Leave a comment:


  • Weasel
    replied
    Originally posted by starshipeleven View Post
    Afaik, Windows can deal with high-RAM-pressure situations better because its kernel does not rely heavily on over-allocating RAM for processes, so there is an actual technical difference.
    In Windows-speak, allocation and commit are different things. Over-allocation is impossible in that speak. What Linux does is "over-commit" in this case. Windows has no over-commit at all. Your commit limit is your available RAM and swaps. Anything above simply gets a NULL pointer when you "commit" with VirtualAlloc. Pages only get "allocated" when they are actually used the first time (accessed or written to by an instruction), so until then, they don't waste any memory even if they are committed (in the sense that they force caches out or whatever), however they DO take up space in the "commit limit" (remember, Windows does not overcommit).

    However, it cannot overcommit because it doesn't have an OOM killer in the same sense of Linux. So once something's commited it must have "backing storage" (either RAM or swap) for which it can get allocated: there won't be any function calls to determine if it's ok to allocate or not. So commiting too much is not a good idea on Windows, that's why even the stack is "reserved" and committed as it's used with guard pages.

    Linux makes the difference between commit and reserve fairly insignificant.

    Leave a comment:


  • AsuMagic
    replied
    Originally posted by reavertm View Post
    Gprof/callgrind is not enough?
    It might provided you don't mind about recompiling your app (gprof) and massacring your performance (a few times slower with gprof, and ~10 times slower or so for callgrind). This seems clearly meant to handle the offending workloads at realtime.

    Leave a comment:


  • RussianNeuroMancer
    replied
    Originally posted by starshipeleven View Post
    More seriously, I would look up what people do (did?) to optimize Android devices as far as sysctl.conf goes anyway
    Android vastly is different (no swap, apps that can be terminated anytime and then restore it's state, browsers that kill backgrounds tabs automatically) so I assume this options is not applicable for GNU/Linux desktop with swap and desktop apps (so I compared with Windows). I also try to make changes one by one, to observer effect of every option.

    Originally posted by starshipeleven View Post
    Did you try a different IO scheduler (like our lord and saviour BFQ)?
    Looks like switching scheduler is impossible for mmc storage as scheduler file contain just [none].

    Originally posted by starshipeleven View Post
    And some configuration of the OOM killer itself https://serverfault.com/questions/76...ill-my-process
    OOM doesn't kick-in in my case, as freeze could happen with swap usage around few hundreds of mebibytes.

    Originally posted by starshipeleven View Post
    Afaik, Windows can deal with high-RAM-pressure situations better because its kernel does not rely heavily on over-allocating RAM for processes, so there is an actual technical difference.
    But if I adjust vm.overcommit_memory and vm.overcommit_ratio isn't apps will just crash on mmap fail? (This is, again, is not what happening in Windows.)

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by RussianNeuroMancer View Post
    This thread kind of related.

    Any advice, people?
    Are you seriously running GNOME with less than 2 GB of RAM? /sarcasm

    More seriously, I would look up what people do (did?) to optimize Android devices as far as sysctl.conf goes anyway
    https://forum.xda-developers.com/sho....php?t=2509751 Some options may or may not be present in Desktop Linux, I also have no idea of what they actually do in practice, I never used that stuff directly myself.

    Did you try a different IO scheduler (like our lord and saviour BFQ)?

    And some configuration of the OOM killer itself https://serverfault.com/questions/76...ill-my-process

    Afaik, Windows can deal with high-RAM-pressure situations better because its kernel does not rely heavily on over-allocating RAM for processes, so there is an actual technical difference.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by lucasbekker View Post
    Could somebody tell me if this could be used to find performance bottlenecks in applications?
    No it does not. It provides a percentage of "usage" for CPU, memory and IO.

    Leave a comment:


  • waxhead
    replied
    These days when systemd (there I said it) is used on most systems and therefore everything that runs is neatly packed into cgroups. How would this PSI system be different, or actually more beneficial than monitoring the system via systemd-cgtop ?!

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Originally posted by fld- View Post
    I usually start encountering pressure-stall related issues on my desktop after ~10 days of uptime. Will be interesting to see if/how the PSI information will reflect such situations. If it's good, I hope it gets added to glances
    If you're using Gnome then it's not kernel related.

    Leave a comment:


  • RussianNeuroMancer
    replied
    This thread kind of related.

    Any advice, people?

    Leave a comment:

Working...
X