Manjaro slowed down noticeably

Hi, first time poster here. I've been using Manjaro on my Dell XPS 9560 for some time now and the experience was great so far. Until recently, after casually booting the laptop in the morning, I've noticed a delay in almost every process. For example, the booting takes longer (up to 3 seconds), logging in also takes a bit longer than usual, Firefox displays websites with a certain delay, document viewer is choppy when scrolling, etc. I am not quite sure on how to debug this. Similarly, I don't even have that many applications that could add this amount of delay in every process. Usually, I use the terminal and the browser that's pretty much it.

Strangely enough, this started randomly, not even after the update.

System:    Host: local Kernel: 4.19.69-1-MANJARO x86_64 bits: 64 compiler: gcc v: 9.1.0 Desktop: Gnome 3.32.2
           Distro: Manjaro Linux
Machine:   Type: Laptop System: Dell product: XPS 15 9560 v: N/A serial: <filter>
           Mobo: Dell model: 05FFDN v: A00 serial: <filter> UEFI: Dell v: 1.4.0 date: 08/23/2017
Battery:   ID-1: BAT0 charge: 61.2 Wh condition: 66.2/97.0 Wh (68%) model: SMP DELL GPM0365 status: Discharging
CPU:       Topology: Quad Core model: Intel Core i7-7700HQ bits: 64 type: MT MCP arch: Kaby Lake rev: 9 L2 cache: 6144 KiB
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 44944
           Speed: 800 MHz min/max: 800/3800 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 8: 800
Graphics:  Device-1: Intel HD Graphics 630 vendor: Dell driver: i915 v: kernel bus ID: 00:02.0
           Device-2: NVIDIA GP107M [GeForce GTX 1050 Mobile] driver: N/A bus ID: 01:00.0
           Display: x11 server: X.org 1.20.5 driver: N/A resolution: <xdpyinfo missing>
           OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 4.5 Mesa 19.1.5 direct render: Yes
Audio:     Device-1: Intel CM238 HD Audio vendor: Dell driver: snd_hda_intel v: kernel bus ID: 00:1f.3
           Sound Server: ALSA v: k4.19.69-1-MANJARO
Network:   Device-1: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter vendor: Bigfoot Networks driver: ath10k_pci
           v: kernel port: f040 bus ID: 02:00.0
           IF: wlp2s0 state: up mac: <filter>
           Device-2: Qualcomm Atheros type: USB driver: btusb bus ID: 1-4:2
Drives:    Local Storage: total: 476.94 GiB used: 48.49 GiB (10.2%)
           ID-1: /dev/nvme0n1 vendor: Samsung model: PM961 NVMe 512GB size: 476.94 GiB
Partition: ID-1: / size: 468.16 GiB used: 48.48 GiB (10.4%) fs: ext4 dev: /dev/nvme0n1p2
Sensors:   System Temperatures: cpu: 37.0 C mobo: 31.0 C
           Fan Speeds (RPM): cpu: 0
Info:      Processes: 257 Uptime: 31m Memory: 15.52 GiB used: 2.62 GiB (16.9%) Init: systemd Compilers: gcc: 9.1.0
           clang: 8.0.1 Shell: fish v: 3.0.2 inxi: 3.0.36

For starters I would check the logs to find out if anything strange is happening. Try dmesg for kernel messages and journalctl -b for system initialization.

Also keep a terminal open with top or htop running to check what processes are busy when you experience delayed response.

1 Like

dmesgdid not contain anything unusual except for MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. and few Entity type for entity x was not initialized.

Systemd journal does not really indicate any crucial error also..

did you read the xps 15 9560 wiki?

https://wiki.archlinux.org/index.php/Dell_XPS_15_9560#General_slowness_&_stuttering

3 Likes
CPU MHz:                         800.068
CPU max MHz:                     3800.0000
CPU min MHz:                     800.0000

I did not read that carefully enough I guess... I guess now I have to wait until my battery drains and do the suggested method! Thank you!

1 Like

you can see if setting the governor to performance changes the sluggishness.

this does not persist through reboots so it's only temporariy

sudo cpupower -c all frequency-set -g performance                                                                                                                                                            

i know it's mentioned that you could do it this way but im doubtful it would make a difference. disconnecting the battery and holding the power switch for 15-20 seconds to drain any residual power or static charge should work but the battery draining method is questionable. if you drain down your battery the system powered down before the battery even hits 0% and even at 0% the battery still has some charge to it. does your xps have a battery reset switch (probably a pinhole or really small button if it does have it). holding that button while holding the power button should achieve what your going for but that's if you have said button.

1 Like

You are correct. I just did the battery draining method and it worked, BUT! After the laptop turned off, the battery still had some charge to it, so I had to additionally click the power button until no light came on (felt really strange doing that)... So I guess the battery unplugging method is better. I had to drain the battery because I do not own a screwdriver that small... :smile:

a hammer and a chisel will do. i guarantee there will no longer be any cpu clock anomalies after the hammer/chisel method. :grin:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by