Memory usage increasing over time

[MegaV0lt]

 * Cinnamon 3.4.6
 * Linux Mint 18.2 Sonya
 * Graphics:  Card: Advanced Micro Devices [AMD/ATI] Kaveri [Radeon R7 Graphics] bus-ID: 00:01.0
           Display Server: X.Org 1.18.4 drivers: ati,radeon (unloaded: fbdev,vesa)
           Resolution: 1920x1200@59.95hz
           GLX Renderer: Gallium 0.4 on AMD KAVERI (DRM 2.49.0 / 4.10.0-32-generic, LLVM 4.0.0)
           GLX Version: 3.0 Mesa 17.0.7 Direct Rendering: Yes

 * 64 bit

Memory usage increasing over time

Steps to reproduce Memory increases slowly the more time is running

Expected behaviour No memory increasing

Other information

[leigh123linux]

@sobrus I would expect it to use more @2160p than @1080p as there is 4x the data

Cinnamon takes almost 600MiB, is this normal for 2160p?

[ctrlesc]

What I think needs to be explored in pursuit of the problem is the significant deviation in cinnamon's memory usage over time while testing just one applet across the versions as I demonstrated. Correct me if I'm wrong, but since cinnamon acts as a run-time surrogate for the applets with cjs as the interpreter, there are at least three things to account for - applets, cinnamon, and cjs. I held the applet constant and tested across several versions of cinnamon (2.8.6, 3.2.6, 3.4.3, 3.6.6) and cjs. After cinnamon 3.4 using the same test methodology, there is a dramatic increase in memory usage over time. If there is a flaw with the applet that I tested with, then at some point a design decision was made which makes cinnamon much more vulnerable to instability and that could/should be investigated as well.

Another way of stating this, I have several Mint 17.3 boxes and several 18.3 boxes. Using the same set of applets, cinnamon under 17.3 rarely crashes and under 18.3 it will eventually become sluggish while consuming GBs of memory. From my experience, this problem is independent of the underlying HW and cinnamon rendering mode; however, removing all applets certainly ameliorates the problem.

@leigh123linux, I know you have been hesitant to include third-party applet tests (and I understand why), but certain applets seem to expose a potential problem. Do you think this is possibly more of a cjs issue?

[sobrus]

Well it seems like we all were partially correct. This is (probably) neither Cinnamon nor applet issue (if you don't count cjs as cinnamon's part at least). I've downgraded cjs to version 3.2.1 and problem seems to be fixed. (cinnamon still grows a bit, but at least it can also shrink itself too). After almost 2,5 hours of quite heavy usage it is at 220MB.

cjs is the only downgraded package, cinnamon 3.6.7, gtk 3.22.26, js 24.2.0

@ctrlesc Can you repeat your test on cinnamon 3.6.6 with cjs 3.2.x?

[michaelpaesold]

@IlyukhinAndrey Since I only had the CPU Temperature Indicator applet (temperature@fevimu), I guess at least that one shows the issue. Maybe @sboukortt is right and this is rather an issue with cinnamon wrt to how it handles applets?

[michaelpaesold]

@sobrus What is the easiest way to downgrade to cjs 3.2.x? I would like to try myself. I had removed nearly all applets and cinnamon memory usage has still grown from 200 MB to 5 GB over the weekend on my office workstation.

[sobrus]

It largely depends on linux distribution that you are using. You need to install older package (you can also copy/overwrite files directly, but most probably it will mess with your package manager) In my case I've downloaded package from Arch Linux Package Archive and downgraded using pacman. https://archive.archlinux.org/packages/c/cjs/

After using cjs 3.2 for more than a week I'm very pleased with the results. Memory usage never exceeded 260MiB and I don't have to restart anything while using computer for several hours. I've added cjs to update ignore list for the time being.

I'd like to notice, that there is significant cjs size increase between version 3.2 and 3.4 indicating that there are some serious changes between these versions. Maybe this is where and why regression was introduced.

[ctrlesc]

@michaelpaesold: If you are on Mint goto packages.linuxmint.com and locate cjs 3.2 under 18.1 Serena. I used dpkg with "--force-overwrite" to downgrade the package. This ends up being a bit messy since you will have broken dependencies. I also had to downgrade libcjs0-libmozjs-38 & libcjs0f to get things somewhat stable. I would not recommend doing this on a production system.

I ran this test about a week ago under a VM running Mint 18.3 and downgraded as above. Cinnamon seemed to stop growing just under 290MB. I really didn't have the time to let it test for very long though.

[sobrus]

On Manjaro (and probably other Arch-dervied distros), downgrading cjs doesn't involve downgradong any other dependencies.

[michaelpaesold]

@sobrus @ctrlesc Thanks! I forgot to mention I am using Linux Mint (Cinnamon of course), version 18.3.

So since you (@ctrlesc) recommend against doing the downgrade on a production system in this case, I will first try this on my laptop at home.

[lucky62]

The same behavior on LM 18.3 sylvia. Immediately after start cinnamon is approx 120M. After few hours:

# date +%H:%M:%S; cat /proc/$(pidof cinnamon)/status | grep -i rss
14:49:24
VmRSS:    189420 kB
RssAnon:      126216 kB
RssFile:       53136 kB
RssShmem:      10068 kB

and again later...

# date +%H:%M:%S; cat /proc/$(pidof cinnamon)/status | grep -i rss
16:18:08
VmRSS:    233776 kB
RssAnon:      169948 kB
RssFile:       53136 kB
RssShmem:      10692 kB

process cinnamon --replace is consuming more and more memory...

[Mek101]

Hi. I would like to add my experience, maybe it's helpful, maybe not Since Linux Mint 18.1, I've experienced some lag, cpu spikes and memory leak issue related to Cinnamon. After 10-15 minutes of uptime both the memory and cpu usage start to grow, causing lag and slowing down the whole system, usually after 20 minutes the memory usage is around 200mb and Cinnamon randomly spikes, using 20-30% cpu for some seconds for no apparent reason. I tried to downgrade to cjs 3.2.0, and even through it solved the memory leak issue, the cpu usage went worse, making the whole interface lag since the startup. I've returned to cjs 3.6.1. I never used 3° party applets or desklets, only the one who came with the default installation.

Current cinnamon version: 3.6.7 Current cjs version: 3.6.1 Nvidia driver: 386

Thanks for the patience and sorry form my bad english :)

[sobrus]

@Mek101 Cinnamon runs slow with nVidia binary driver unless CLUTTER_VBLANK=none. At least on GTX750Ti. Use CLUTTER_DEFAULT_FPS=60 to prevent it from redrawing too fast with vsync disabled. I didn't notice any performance difference with cjs3.2. Maybe even it is faster, since after growing to ~800MiB it slowed down a lot.

[nick-s-b]

I run Cinnamon with an Nvidia 1070 card on a 4K display. In one of the other issues threads I posted daily/weekly memory usage graphs and the usage fluctuates between 300-800MB during the day. My cinnamon process is usually in the 400MB range which is reasonable for a 4K display. The more apps and windows you have open, the larger cinnamon process gets. That's to be expected. I also have a bunch of applets running (14 to be exact) and haven't noticed any memory increase with them but I could be wrong and some of them might be causing an increase. I also have a script that monitors cinnamon process and pops a notification when it crosses 800MB mark so I can restart it manually (don't like an automatic restart).

@sobrus hmmm... my env variables look like this:

CLUTTER_PAINT=disable-clipped-redraws:disable-culling
CLUTTER_VBLANK=True
KWIN_TRIPLE_BUFFER=1

I've had great success with this and haven't had any screen tearing. In nvidia settings, I also have "Force Composition Pipeline" enabled and also "Sync to VBlank" enabled and "Allow Flipping" disabled.

[sobrus]

I've tried your settings but still have performance issues. Don't get me wrong: cinnamon works OK and fluid, but there is noticeable lag in UI operations (for example when moving windows they seem to lag behind mouse cursor a bit instead of being always exactly where cursor currently is). Its easily noticeable if you come from different window manager like marco. Of course you won't have any screen tearing with vsync enabled, but I'd rather have tearing without lag. Try moving windows fast with my settings and you'll probably see what I mean.

It seems like memory leak problem doesn't affect all users. Leigh123linux (who coincidentally also runs Cinnamon on 4K with nvidia binary blob) doesn't seem to be affected.

[nick-s-b]

@sobrus I have maybe one or two pixel lag between the mouse cursor and the window. I don't really notice it at all and it doesn't bother me in the slightest.

Of course you won't have any screen tearing with vsync enabled, but I'd rather have tearing without lag.

Really? You'd rather have screen tearing and slideshows when playing video than see a 1-2px lag when moving windows? That's a weird compromise.

[sobrus]

I think we departed off topic too much already, but having computer that is lagging behind you is quite annoying. Like playing fast shooter at 20fps. Responsiveness is important for user experience, that's why we have schedulers like BFQ, interactive, etc. And either my tearing is minimal or I already got used to it, becasue I have to watch carefully and even then barely see it.

[OlsonB]

The only thing I kind of noticed, after cinnamon again reached 3.9GB of memory use and started lagging firefox and everything is that the leak appears to go away after cleaning from the desktop any extraneous GIF files.. possibly PDFs and ZIP too I'm not sure which makes the difference.

[OlsonB]

Sorry, scratch that, it is just pissing it away more slowly now I've cleared the Desktop.

[melmelissa]

similar problem here on ArchLinux Cinnamon 3.6 with kernel-lts 1.4 GB ram used by the "cinnamon --replace" process after only 8 hours of operation............................................................. I don't have any applet installed, except Menu, time, wifi, brightness and sound.

I have another user account but a recurring problem...

While on Debian Sid with Cinnamon 3.4, no such problems and I have fifteen applets installed.... after 5 days of operation, the "cinnamon --replace" process takes only 160 MB of ram. And it's on the same pc with the same configuration...

Cinnamon getting as heavy as Gnome?? Is the problem being corrected?? Is he known??? Will Cinnamon 3.8 solve this recurring problem?? On ArchLinux we have been dragging this bug since version 3.2, in spite of our bug reports. Even if it doesn't affect everyone, people are still affected by this bug.

I'm considering downgrading the cjs package to version 3.2, in the past it had helped me to find a correct functioning. too bad it's not fixed by the developers, and that we always have to tinker to get something "almost functional".

The versions of cinnamon pass but the recurrent problems remain...

[C0rn3j]

@melmelissa You have to realize that people develop FOSS projects mostly on their own time, it's not like you had to pay for this, complaints like this aren't helpful. (and annoying for many especially with so many people being subscribed to this issue)

If it bothers you so much, you can debug this issue and submit a pull request with a fix yourself.

Others have suggested that this issue is caused/accelerated by a new version of cjk, you can do regression testing on that and figure out which exact commit is causing this.

[JosephMcc]

This is an issue tracker, not a place for ranting. I've deleted several posts that are of no help. There is obviously some issue here but it's inconsistent and doesn't effect many users at all. That makes it a difficult issue to pin down and fix. It may be a combination of several things.

[eli-schwartz]

I suppose I can... confirm I don't see this issue either? Speaking with my official Arch Linux maintainer hat on, if there is an issue it certainly doesn't seem to be a packaging bug, and given that I and lots of other people cannot duplicate it, it doesn't seem like something I can fix, though maybe if the people who did see it could provide some more useful debugging, that could help. This would seem to be a rather subtle issue in relatively low-level cinnamon components if anything, and that will be hard to debug without being able to actually trigger the problematic codepaths... A good place to start might be http://www.brendangregg.com/perf.html (or valgrind obviously).

Now maybe if @melmelissa could stop sending me angry emails, that would be nice. :) I guess since I am now subscribed to this issue, I will know as soon as anyone else does, if the root cause is ever discovered and fixed. I guess I should disclaim right off the bat that as an unaffected downstream packager I'm utterly disinterested in debugging this myself, so more emails will not help.

Especially from someone who has repeatedly spammed various outlets with useless rants and complaints that provided absolutely no help to the developers, and quite frankly gives FOSS a bad name. @melmelissa, Do not do this! Take your negative tone elsewhere!

*wanders off and does something more interesting with his life*

[melmelissa]

On the various international forums (ArchLinux, Reddit, and others) We are already 34 users to have exactly the same problem of memory leakage (yes I opened various topics to record the "bug") All under ArchLinux Cinnamon 3.6.7.

So no, the problem is not isolated, 34 people it's no longer an isolated problem, but it's a real bug that exists. If I was alone, yes, it would be an isolated bug.

Do we have to remember that on this bug report, many of us complain about it?? Apparently, there are not enough of us to take the bug seriously?? So I'm going to ask the 34 people to come and prove that they also have the same problem (since I'm obviously called a liar, or because I invent a bug that doesn't exist)

We've been waiting 3 months for a patch to get rid of these big performance losses, in a few hours the ram is saturated, and yet we have good pc.

We spend our time downgrading packages (cinnamon, muffin, cjs, nemo) on rolling release, it's doomed to failure...

On my Debian Sid (unstable), Cinnamon has no worries, so it's not a hardware problem, nor is my pc having a problem. But it's Cinnamon 3.6 that bugs. Or a packaging problem..

you are the maintainers, not us... we're just suffering the consequences of your mistakes...

[leigh123linux]

@melmelissa I've had enough of your shit

[clefebvre]

I find the testing from @ctrlesc to be quite interesting. It highlights a regression in Mint 18.2 and seems to conclude the cause is somewhere in Cinnamon 3.4, and in particular in the adoption of mozjs38.

@ctrlesc we've moved away from mozjs38 here on the master branch (in preparation for Mint 19) and we're now using mozjs52. I've backported mozjs52 to Mint 18.3, to make it possible for us to work on the next version of Cinnamon without having to upgrade to Mint 19 (which isn't ready yet).

Do you think you could run similar tests somehow with a 18.3 VM upgraded with the master packages? FYI we now use CI and automatically build packages for each new commit on master... for instance, if you go to https://github.com/linuxmint/cjs/releases, you'll see a release for Mint 18, and in there you'll find master packages for Mint 18 (i.e. 18.3). All Cinnamon components now have releases like these and master packages for Mint 18 on their github releases page. You'll probably need to upgrade CJS and Cinnamon at the very least... possibly other components as well if you run in to dependency issues (xapp, etc..).

I'll reopen the issue in the meantime.

[mainmachine]

Just as another reference point, I recall observing a similar "creeping RAM syndrome" on Cinnamon 3.4.x on Ubuntu 16.04, but since upgrading to 3.6.x I have noticed that this problem has been resolved (for months now, as I upgraded when 3.6.x was released).

In fact I generally leave my desktop PC running non-stop, only rebooting if there's a kernel or Mesa update that I'm interested in testing - I've been up to at least 14 days with no excessive RAM usage.

Not looking to stir things up, but I thought that another non-mint, Cinnamon 3.6.x example where this problem doesn't exist might be useful. I can provide more info if that will help.

[Elemag]

I suspect that it is indeed something that is refreshing the screen through Cinnamon. Ever since I removed my CPU temperature indicator, things have stabilised and I am sure most of the people here are using Conky or something similar that is redrawing the screen with even more intensity.

Even alt-tab switch was adding some kilobytes to the memory footprint but it is hard to notice unless you're watching it closely.

[melmelissa]

without any applets, desklets or conky, my ram consumption increases over the hours. the "cinnamon --replace" process continues to take several GB of ram after several hours of operation. Until it completely saturates the ram, and freeze the pc.

I don't use automatic wallpaper (slideshow) no idle time, no screen saver. The problem is mysterious and seriously blocking for me. So I demoted Cinnamon again in version 3.4.

[CloneMMDDCVII]

Again, Applets don't really seem to be the issue. As @sobrus pointed out, draw calls seem to induce a memory leak. Simply repeatedly pressing the [Super] button to show and hide the menu gets the ram going up

Ram Leak isn't that much of an issue for me, because with 16Gigs, I will go to sleep before the system even thinks about paging anything, but the issue seems to exist in quite a few instances, and I think it deserves a confirmed label, even so most users will probably never notice it.

I think the reason that it seems like the issue isn't widespread is that you need to troubleshoot it to really make it obvious. I was told the issue existed in Cinnamon as a critic, looked it up, and realised it was there, when I actually had been using Mint for 3 years.

Running Cinnamon 3.6.7, Kernel 4.13.0-32, Nvidia Driver 384. on mint 18.3 x64

[MegaV0lt]

German threat that says it has to to with repainting of the bar: https://www.linuxmintusers.de/index.php?topic=47097.msg665511#msg665511

[melmelissa]

Many think the problem comes from applets. It's quite logical, the applets monitor the state of the system. Before I used the one of the temperature, activity CPU and consumption ram.

When we install these applets, we have the question mark, which warns us that they are applets that make system calls, and can reduce performance.

The major problem is that with Cinnamon 3.4, this problem does not exist. Without applets with Cinnamon 3.6, the memory leak is present, so it's the applet of the wifi ?? That of sound maybe ?? In any case there is something wrong ..

I'll try to hide the panel automatically, we'll see what happens ...

Hoffnung erweckt Hoffnung zum Leben

[mainmachine]

I do not experience this problem, I do have DPMS enabled in my xorg.conf, and I do have things set to blank the screen when inactive, via Settings > Power Management:

Turn off the screen when inactive for = 30 minutes

If the issue is related to draw calls, repainting, etc. then will screen blanking, screen savers, etc. inhibit that from happening, thus preventing the problem for most users since the default for these settings is to enable screen sleep/ blanking behavior...?

There must be a common variable for the users who have this problem - it doesn't appear to be distro related, but does seem to be specific to draw calls - applets themselves don't appear to be the problem, yet applets that graphically update often do seem to exacerbate the problem.

The data is pointing to draw calls, screen updating, something in the graphics stack...

[sboukortt]

The major problem is that with Cinnamon 3.4, this problem does not exist.

As far as I remember, I did have the issue with 3.4. I think it started around 3.0, or 3.2 at the latest.

I also noticed that repeated draw calls caused not only a huge increase in RAM usage but also very high CPU usage in the Cinnamon process, and hiccups in the compositor (to the point that I could not play video games while SpiderOak ONE was backing up data).

[melmelissa]

@mainmachine I just set the screen saver to 10 minutes to see how it feels. Hiding the panel has no effect on me, ram consumption is flying away. I'm at 2.9 GB for the "cinnamon --replace"process, the pc has been on for only 3 hours :/

@sboukortt I also had the memory leakage problem with Cinnamon 3.2.. But version 3.4 is the best version I've used so far, and it's not a problem for me. But on rolling release distributions, having to blacklist desktop environment upgrades, one day it will be a big problem.

Unlike you, I have no worries about CPU level, it remains very stable, no runaway. For my part, the downgrade is the only alternative.

On Debian Sid, I'm in no hurry to get Cinnamon 3.6. The current version 3.4 suits me very well :)

@sobrus By recovering the Cinnamon packages from ArchLinux, there is no way to install them on Manjaro?? Since it's the same family.

[sobrus]

@mainmachine I have DPMS screen off too, yet I'm definitely affected and memory usage grows with screen off. I agree with @CloneMMDDCVII that this issue is probably far more widespread, most users just don't notice it, don't care, and don't report it. This is why I insisted on checking it out.

I can test updated version on Manjaro, if Arch maintainers provide updated packages. I've converted master 18.3 deb to pacman xz packages (cinnamon, session, desktop, cjs etc) , but (of course) it broke cinnamon. I have custom recovery and backup so I'm not afraid of damaging my system in any way.

@melmelissa Manjaro and Arch packages are usually interchangeable (Manjaro packages are usually Arch packages, just lag a few days). That said since neither Arch nor Manjaro support partial updates and it may or may not work. Usually it works and I'm currently using cjs 3.2 from Arch package archive.

[JosephMcc]

I agree with @CloneMMDDCVII that this issue is probably far more widespread, most users just don't notice it, don't care, and don't report it. This is why I insisted on checking it out.

That's complete conjecture. I sometimes run Cinnamon for days without crossing the 400mb mark. That's what makes this hard to troubleshoot. For example, someone above says they have Cinnamon using 2.9GB after 3 hours. I've had Cinnamon up doing dev work for the last 3 hours on a HiDPI machine (which typically has higher usage) and I'm at only 238mb.

[sobrus]

@JosephMcc I am aware that there are users who are not affected. But this issue is present on various distros and various hardware. Reproducing it is probably as simple as installing Mint 18.3 on virtualbox (or @ctrlesc is very unlucky) and even my 5-year old Manjaro instance is affected (until I downgrade cjs, that is)

[JosephMcc]

Don't get me wrong, I'm not trying to act like this isn't a real issue. I just don't see it and neither do the other devs.

I've run Cinnamon on various version of Mint, Debian, and Ubuntu since Mint13 across 7 or 8 different machines. My current main working machines have Mint 18.3, Ubuntu 18.04, and early testing versions of Mint 19 and none of them are affected.

I will say that I don't run some things I see may be causing this issue. No 3rd party applets, desklets, or extensions. I also don't run anything that is leaving constantly updating things in the systray like SpiderOak.

[mainmachine]

I'd like to rule out a hardware or graphics driver issue. I'm not experiencing this problem but I am intrigued by it, and I'd like to gather some system data from anyone who's experiencing the problem to facilitate the process.

@JosephMcc or @leigh123linux - if I were to post a link to a shared spreadsheet that people here could add their info on to, would that break any rules or generally upset anyone, that you're aware of?

[melmelissa]

I don't know if the problem is isolated, or specific to some configurations maybe, but on the different English, French and German forums, I've opened topics to find out who has this bug, and so far we are 36 users, all under ArchLinux Cinnamon 3.6, and fully up to date distribution.

I know that 36 people is a tiny number, but it makes me feel better, I'm not the only one. But it's also worrying to know that there is a problem that looks isolated and repeats itself from version to version. I've even installed Archlinux Cinnamon on my test drive, and the problem is there again, and it's a raw Cinnamon form release.

And it's not a hardware problem, as mentioned above, on my Cinnamon Debian, I have no malfunction. And cinnamon 3.4 on ArchLinux solves the problems. I don't know what else to do, to give more details or other...

[NikoKrause]

Reproducing it is probably as simple as installing Mint 18.3 on virtualbox I don't know what else to do, to give more details or other...

Do this: Then ship it to Ireland.

[mainmachine]

@melmelissa - The hardware might be OK, but different graphics drivers, X.org versions, GL libraries, etc. can all drastically change how the stack interacts with the hardware, so it could be that a certain kernel, module or library is exposed by cinnamon. If we can put the data in one place, then we can look for a pattern.

[melmelissa]

In Ireland it is cold, it will catch a cold, it is accustomed to temperatures in the south of France :p

@mainmachine In fact, all packages are different from one distribution to another, and not all pcs look the same. For proof some under Mint have problems, others not.

If we can gather useful data for in-depth debugging, why not, it will be a way to perhaps find a common element that we all have.

[mainmachine]

@melmelissa - if the Cinnamon folks can't recreate the problem, then there's literally no way to solve it, because in that scenario, there is no problem, yes?

So the only way to move forward is to gather data from affected users, and attempt to identify a pattern. If a common element is found, then someone could test against that variable and hopefully recreate the problem, and then solve it. Or, we find it is some weird corner case, and not caused by Cinnamon directly.

In either case, the problem has to be characterized, root cause identified, and recreated in order to be debugged and solved.

[melmelissa]

Yes, it is true that we can't reproduce the problem... I agree with your analysis, and I am ready to give all the necessary elements. If other affected users also want to participate, this will be the way to really identify the problem. :)

I am at your disposal to try to find the origin of the bug. It's late in France, I'm going to sleep.

[a-torgovitsky]

I also experience this problem on a new install of Mint 18.3, although it appears to be a milder version than for some others. I do regularly get RAM usage up past 1GB for cinnamon --replace. It was worse before I turned off a CPU temperature applet (as suggested elsewhere in this thread).

I realize "me too" comments from users aren't terribly helpful, which is why I have just been following and not commenting up to now. But given the way the discussion has evolved, I thought I should say that I would be willing to contribute some system diagnostics if that would be helpful to the developers.

[ctrlesc]

@clefebvre, I've got a couple VM's ready to start testing. I will pull in the packages as you described and post the results.

[sobrus]

@JosephMcc you have ~240MiB on HiDPI machine, @leigh123linux had almost 800MiB (although I don't know what his uptime was). Yet both of you are not affected. And it makes me wonder.

[leigh123linux]

@sobrus I get the same usage in Mint

date +%H:%M:%S; cat /proc/$(pidof cinnamon)/status | grep -i rss
08:01:07
VmRSS:   1117500 kB
RssAnon:     1020360 kB
RssFile:       96672 kB
RssShmem:        468 kB

nvidia-smi
Thu Feb 15 08:03:59 2018       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.25                 Driver Version: 390.25                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 105...  Off  | 00000000:01:00.0  On |                  N/A |
| 46%   32C    P8    N/A /  75W |    794MiB /  4039MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      5624      G   /usr/libexec/Xorg                            550MiB |
|    0      6096      G   cinnamon                                     238MiB |
|    0      6930      G   /usr/lib64/firefox/firefox                     1MiB |
|    0      7681      G   /usr/lib64/firefox/firefox                     1MiB |
+-----------------------------------------------------------------------------+

uptime
 08:01:26 up 4 days, 20:18,  1 user,  load average: 0.13, 0.33, 0.26

inxi -Fz
System:    Host: localhost Kernel: 4.15.0-1.fc28.x86_64 x86_64 bits: 64 Desktop: Cinnamon 3.6.7
           Distro: Fedora release 28 (Rawhide)
Machine:   Device: desktop System: Gigabyte product: N/A serial: N/A
           Mobo: Gigabyte model: GA-990X-Gaming SLI-CF v: x.x serial: N/A
           BIOS: American Megatrends v: F1 date: 01/28/2016
Battery    hidpp__0: charge: N/A condition: NA/NA Wh
CPU:       8 core AMD FX-8350 Eight-Core (-MCP-) cache: 16384 KB
           clock speeds: max: 4400 MHz 1: 1404 MHz 2: 1404 MHz 3: 1404 MHz 4: 1404 MHz 5: 1404 MHz 6: 1392 MHz
           7: 3189 MHz 8: 3792 MHz
Graphics:  Card: NVIDIA GP107 [GeForce GTX 1050 Ti]
           Display Server: x11 (X.org 119.6 ) drivers: nvidia (unloaded: modesetting,fbdev,vesa,nouveau)
           Resolution: 3840x2160@60.00hz
           OpenGL: renderer: GeForce GTX 1050 Ti/PCIe/SSE2 version: 4.6.0 NVIDIA 390.25
Audio:     Card-1 NVIDIA GP107GL High Definition Audio Controller driver: snd_hda_intel
           Card-2 Advanced Micro Devices [AMD/ATI] SBx00 Azalia (Intel HDA) driver: snd_hda_intel
           Sound: Advanced Linux Sound Architecture v: k4.15.0-1.fc28.x86_64
Network:   Card-1: Intel Wireless 7260 driver: iwlwifi
           IF: wlp2s0 state: up mac: <filter>
           Card-2: Intel I211 Gigabit Network Connection driver: igb
           IF: enp7s0 state: down mac: <filter>
Drives:    HDD Total Size: 3884.8GB (17.7% used)
           ID-1: /dev/sda model: SAMSUNG_SSD_830 size: 128.0GB
           ID-2: /dev/sdb model: Samsung_SSD_850 size: 500.1GB
           ID-3: /dev/sdc model: WDC_WD30EZRX size: 3000.6GB
           ID-4: /dev/nvme0n1 model: SAMSUNG_MZVLW256HEHP size: 256.1GB
Partition: ID-1: / size: 40G used: 28G (73%) fs: ext4 dev: /dev/nvme0n1p5
           ID-2: /home size: 74G used: 17G (24%) fs: ext4 dev: /dev/sdb4
           ID-3: swap-1 size: 18.52GB used: 0.00GB (0%) fs: swap dev: /dev/sdc4
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 25.2C mobo: N/A gpu: 33C
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 262 Uptime: 4 days Memory: 5884.6/16002.7MB Client: Shell (bash) inxi: 2.3.56

[JosephMcc]

System:    Host: localhost Kernel: 4.13.0-32-generic x86_64 bits: 64 Desktop: Cinnamon 3.6.7
           Distro: Linux Mint 19 Tara
Machine:   Device: laptop System: HP product: HP ENVY Notebook v: Type1ProductConfigId serial: N/A
           Mobo: HP model: 81D1 v: KBC Version 87.21 serial: N/A UEFI: Insyde v: F.41 date: 06/05/2017
Battery    BAT0: charge: 13.6 Wh 25.7% condition: 52.9/52.9 Wh (100%)
           hidpp__0: charge: N/A condition: NA/NA Wh
CPU:       Dual core Intel Core i7-7500U (-MT-MCP-) cache: 4096 KB
           clock speeds: max: 3500 MHz 1: 2900 MHz 2: 2900 MHz 3: 2900 MHz 4: 2900 MHz
Graphics:  Card: Intel HD Graphics 620
           Display Server: x11 (X.Org 1.19.6 ) drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 3840x2160@60.00hz
           OpenGL: renderer: Mesa DRI Intel HD Graphics 620 (Kaby Lake GT2) version: 4.5 Mesa 17.3.3
Audio:     Card Intel Sunrise Point-LP HD Audio driver: snd_hda_intel Sound: ALSA v: k4.13.0-32-generic
Network:   Card: Intel Wireless 7265 driver: iwlwifi
           IF: wlp1s0 state: up mac: <filter>
Drives:    HDD Total Size: 1024.2GB (1.0% used)
           ID-1: /dev/nvme0n1 model: SAMSUNG_MZVLW1T0HMLH size: 1024.2GB
Partition: ID-1: / size: 938G used: 11G (2%) fs: ext4 dev: /dev/nvme0n1p2
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 34.0C mobo: 0.0C
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 212 Uptime: 4:20 Memory: 2299.0/11893.8MB Client: Shell (bash) inxi: 2.3.56

Cinnamon is currently sitting at 285mb. My other machine is not HiDPI and has an Nvidia1060. Cinnamons memory use is generally a little higher on that machine but that's typical with the Nvidia driver. I still don't see it climbing out of control like some of you do and I've left it running for days.