Performance issues

General system Kernel, boot, graphics & hardware
1

So when I moved to the 7.0.x kernel I noticed performance slow and that for some reason power mode was on “balanced” and set that back to “performance”. Seemed odd that it would be “balanced” on a desktop.

❯ powerprofilesctl list
* performance:
    CpuDriver:	intel_pstate
    Degraded:   no

  balanced:
    CpuDriver:	intel_pstate
    PlatformDriver:	placeholder

  power-saver:
    CpuDriver:	intel_pstate
    PlatformDriver:	placeholder

image
image936×368 55.3 KB

I have been doing a lot of local AI tinkering and dropped back to LTS. An now it feel sluggish again. I did move my home directory off the SSD to a platter hard drive due to all these LLM’s I was downloading. So maybe that is the reason but even launching apps off the SSD seems sluggish. I’m not seeing anything in journelcttl that is jumping out on me. Another change is I moved from Jakoolit’s hyprland configs to ML4W dots.

Maybe I should move home back to the SSD and setup an AI directory on the platter drive.

Any thoughts out there?

2

Can’t say much about your particular setup. Though I would definitely have all the system’s directories on the fast SSD.

And also my personal preference for managing CPU power and frequency scaling is cpupower. So I always disable/mask power-profiles-daemon and use cpupower instead.

Have a look here: https://wiki.archlinux.org/title/CPU_frequency_scaling

3

Disabled power-profile-deamon and restarted. Seems to be a better than before. Thanks for the suggestion. Linux system is on SSD, only the home directory is on the platter. I will keep an eye on it.

4

I would look at the kernel boot options active or passive for intel_Pstate and see how they affect the performance for your workload.

Depending on your need and use case, you could combine it with cpupower for a bit more fine-grained power-tuning and frequency scaling.

Experiment a bit to find what suits you best.

5

In KDE, and typcially on an intel processor, if the power is connected then switch happens to Performance, As soon as battery starts to get used or main line power gets disconnected balanced mode is activated.

Not sure how are you using, with power connected all the time or on battery.

In KDE System Settings > Power Management, there are typically 3 tabs that are available. On AC Power, On Battery, On Low Battery. Check what is given for your case.

About the sluggishness that you observe, yeah if you transfer $HOME directory to a magnetic hard drive from a SSD you will see a performance dip. A significant one that too. The reason for that are two directories $HOME/.config, aka $XDG_CONFIG_HOME and $HOME/.cache, aka $XDG_CACHE_HOME.
All applications, regardless of the DE/WM/Launcher will keep the configuration of the application, its settings in the $XDG_CONFIG_HOME. Since that has been moved to a sluggish hard drive, load time and closing time will suffer.
Most of the applications use the directory, $XDG_CACHE_HOME for writing and maintaining cache or temporary files. They should not, they should use the /run or $XDG_RUNTIME_DIR which ought to be mounted in RAM but dont. Well that is a rant for some other day. Since the $XDG_CACHE_HOME has been moved to a magnetic disk drive this will suffer, hence the operations and working of the application will suffer.

In a nutshell you will face degradation the moment you move $HOME to a magnetic drive. Magnetic drives ought to be used when there is a massive data set to be read from it and very very infrequent writes. Think about keeping the entire dump of Star Wars, all avengers movies, all the songs of Taylor Swift, etc. Or you have tons and tons of legal PDFs which will be read only and not written to.
Magnetic disk drives should be used when there is a possibilty to reserving 16 GB or more of disk cache in memory. So if there is 32 GB of RAM, out of which 16GB can be used spared exclusively for a disk cache. Okay it will work with 8 GB too, but you catch the drift.

My suggestion, if the fiasco and debacle in Persian Gulf, was not ongoing, would be to ditch the magnetic drive and buy a new 4 TB SSD. Heard micron and Samsung makes great ones. If you want to save money and have a free SATA 3/6 port available then dont go for NVMe go for SATA.
Use the Magnetic drive for what it is meant for. A data dump. A Data backup. A OS image backup and so on. And offcourse for all the Batman/DC comics and Taylor swift songs. :laughing:

p.s. if you do find this useful, please consider sharing your Batman/DC comics along with Taylor swift songs over torrent. Jesus blesses you. :wink:

6

I think what I’m going to do is start with a clean /home on the SSD. I was looking in .cache and .config and man does Brave crap it up. I haven’t used Brave in 6 months but there is a metric shid ton of files. Plus this gives me a chance to clean up dotfiles and how I manage dotfiles.

7

What do you mean with that? is it slow to start an app? Or is it slow to compute, eg.g convert an image from RAW to JPG? DO you believe you have a CPU performance issue or an i/o performance issue?

I hardly believe that this gives you a noticeable “sluggishness” of your system. You can test that very easily. Just change from “balanced” to “performance” on the fly while the system is running and see if that makes a difference:

echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

or

echo balanced | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

8

yeah it was on powersave. Again very odd to me being a desktop.

9

Cleaned up the SSD drive and man was there a lot of crap in .config, .local, .cache I no longer used. Made new home back to the SSD and everything is snappy again.

10

Good move!

11

If you have sufficient RAM, i.e. 16GB or higher, and for significant period of time the RAM is unused, then why not consider moving the $XDG_CACHE_HOME to RAM under the /run? $XDG_CACHE_HOME is $HOME/.cache.

There are multiple ways to do it. And are discussed in much greater details over here. They discuss how to use .profile or .bash_login or .bash_profile to achieve this. They also discuss packages like log2RAM and how to use systemd-mount to move the $HOME/.cache to a tmpfs file system and various other options. Worth a read.