It's unclear exactly what you mean by the upthread comment, i.e. how "using a lot of memory" maps to e.g. Linux smaps statistics. But you do mention e.g. gnome-

It's unclear exactly what you mean by the upthread comment, i.e. how "using a lot of memory" maps to e.g. Linux smaps statistics. But you do mention e.g. gnome-shell taking ~2GB. My own gnome-shell has e.g. a 100MB allocation where >95MB is in "Private_Dirty", then a ~200MB allocation where all the columns except "Size" in the "/proc/$(pidof gnome-shell)/smaps" are zero. People typically exclude the latter category when talking about "real" memory use. But the former is the sort of thing that would make it into "real" memory use by most definitions, and show up in "RSS". What I'm pointing out is that knowing that doesn't tell you anything about whether the memory use contributes to memory contention, which is the interesting question. It's entirely possible (and quite common) that most/all of that was used as a one-off, and is either sitting there unused, or would be swapped out as part of expunging stale pages to disk. So, you could have a process that at one point used 2GB of memory, and still hasn't free()'d it, but for the purposes of needing to fit a 7GB browser process into a total of 8GB of RAM won't contribute to contention. Even though it "uses" 2GB still (as in "RSS" etc.) it's only ever accessing 100MB of those 2GB. The kernel will happily page out 1.9GB to swap, and performance will be mostly unaffected. To make any claim about whether an application uses a lot of memory on a modern OS you need to know a lot about its lifetime management of data.