Gnome-shell-system-monitor-applet: With latest Ubuntu LTS kernerls, seems like this applet is responsible for screen lags

[Emanem]

Hi,

As reported here: https://www.reddit.com/r/gnome/comments/817vzq/warning_applet_systemmonitor_responsible_for_lags/ seems like with more recent kernels (which perhaps integrate _spectre_ and/or _meltdown_ workaround - again speculative suggestion - no pun intended), this fantastic applet is responsible for massive input and graphic lags with gnome shell.

Opening this bug - I'm looking forward to having this fixed because I miss it a lot!

[piegamesde]

I do experience such freezes too since, say, a weeks or so. I definitely updated a lot of extensions including this in that time, but never linked the lags to this extension. What makes you so sure it's this extension?

I have no idea how to profile this though.

[Emanem]

What makes you so sure it's this extension?

Simple: after when I enable it the screen becomes laggy and stutters; upon disabling it everything goes back to normal. Enabled again and symptoms appear again, disabled again and things run smooth once more.

[edwinksl]

I can confirm the latest version of this extension causes screen lags. I am using Ubuntu 17.10. Let me know what additional system details you need to fix this bug. Thanks for the hard work!

[Ghimli]

Mouse lag/stuttering in Ubuntu 17.10 only under wayland. Coming from cpu frequency polling. Disabling frequency polling fixes problem.

[mjmeyer]

16.04 here and noticed big screen lag when typing/dragging windows after I updated this to latest. After disabling the CPU freq option, lag / stuttering is gone.

[piegamesde]

Can you all please roll back to a random old version for a few days and tell me about the performance?
Also, which exact versions are you using? The latest official release or some random up to date commit?

[chrisspen]

I'm on Ubuntu 16, and my kernel has the spectre patch applied, and I've never experienced any issues.

[piegamesde]

@chrisspen Finally good news! Can you please try out my latest development branch to see if the issue is there? If not, this might to have to do something with other updates (maybe a Kernel upgrade?).

[franglais125]

@piegamesde and everyone, as far as I remember, this is due to kernel 4.13+ changing the way we can collect the frequency information. I can't remember where, but I already had a discussion with someone regarding the slowness.

My understanding is that we can't do better, since the new system in the kernel itself is not well optimized.

Here is the PR that caused the issue: https://github.com/paradoxxxzero/gnome-shell-system-monitor-applet/pull/404 (itself it contains links with more info). But without this patch, we won't have frequency info at all on 4.13+.

I don't use the frequency info myself, so I never experienced the issue... I'm afraid we are stuck with a (in-kernel) code-path that is not great. What we could perhaps explore is the use of an async method, which will prevent the freezes.

Also, let's dupe https://github.com/paradoxxxzero/gnome-shell-system-monitor-applet/issues/202 into this one.

[franglais125]

Regarding the async method that I mentioned, here is a WIP branch for anyone that would like to pick up that work. https://github.com/franglais125/gnome-shell-system-monitor-applet/tree/async_freq

[piegamesde]

@franglais125 Is this the reason for #428 ? If yes, we might merge that one too. (Even if it does not really fix anything, it still might help for people with a lot of cores).

By the way I can confirm that disabling the frequency info does work around the issue.

[yura-pakhuchiy]

For me extension was working stable even on kernel with meltdown fixes. However problem started after update to the latest version from extensions.gnome.org about 1 week ago.

[andreee94]

Also for me micro lag synchronized with cpu frequency update time (ex every 1500ms)
(ubuntu 18.04)

[return42]

@Emanem : I made a fork [1] with the patch in @14mRh4X0r suggested. For me it fixed a lot of my issues I observed when system-monitor is activated. May you also like to have a look at #496 which summarize all the issues related to blocking IO.

Do you like to test my fork? .. any feedback is welcome / Thanks

[1] https://github.com/return42/gnome-shell-system-monitor-applet

[Emanem]

@return42 Is there a quick way to see the diff between mainline and your fork?

Edit
I'm an idiot, found it :)

Edit 2
You're chaining async calls to each cpu counter and then update the variable holding the frequency. Seems to be ok. Got a couple of questions:

1. Should you apply same method to _all_ file reading?
2. I think async read is better in this case, perhaps these changes should be reviewed and merged in _master_?
3. Also, why wouldn't you schedule _n_ async read and then wait on all to complete, instead of chaining them? Wouldn't it be faster? (I understand this may be quite a minor point, but interested)

[return42]

@Emanem ATM I have not much time .. in short:

1. yes, yes, yes .. each sync read blocks GNOME-Shell's main loop making GNOME unusable!!! (see #496) .. CPU: think about 64 core systems / DISK: think about polling the state of a lazy (e.g. remote ) file-system .. sync IO in GNOME-Shell extensions is a no-go!
2. yes, this ore any other async solution has to be merged
3. It is simple to implement ;) .. as I wrote; with small correction I just applied the patch @14mRh4X0r suggested here https://github.com/paradoxxxzero/gnome-shell-system-monitor-applet/issues/439#issuecomment-398851503

[return42]

@Emanem This issue is fixed in master since PR #497 is merged. Can you please test current master and close this issue? / Thanks!