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

  • #11
    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.

    Comment


    • #12
      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.)

      Comment


      • #13
        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.

        Comment


        • #14
          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.

          Comment


          • #15
            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!

            Comment

            Working...
            X