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

[torsionbar28]

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!

[Weasel]

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.

[AsuMagic]

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.

[RussianNeuroMancer]

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.

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].

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.

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.)

[starshipeleven]

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.

[starshipeleven]

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.

[waxhead]

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 ?!

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.

[RussianNeuroMancer]

This thread kind of related.

Any advice, people?

[reavertm]

Gprof/callgrind is not enough?