For a long time after creating my own Linux distro, I had the same kind of problems also. It turns out the Linux kernel is horribly tuned by default. After a number of tweaks and adjustments, I finally got all those bugs ironed out. Now my (four core) desktop is perfectly smooth and responsive under all loads, even playing video and running multiple builds while copying files around. Here's the important parts of what I've done:

* set disk i/o schedulers to 'bfd' for spinning drives and 'deadline' for solid state, and 'none' for nvme, by creating a file in /etc/udev/rules.d . kernel must have deadline and bfd schedulers compiled in.

* turned on SCSI block multiqueue in kernel config. requires kernel command line option scsi_mod.use_blk_mq=1 to actually enable it. this helped, but did not completely cure the disk i/o problem.

* patched kernel source file ./block/blk-mq-sched.c to hard limit number of queued block device requests to 2, instead of default which is like 32. this absolutely cured the problem. no more disk i/o dragging the system down. doesn't seem to have a major effect on throughput.

* kernel is configured for full preemption, with 1000hz timer frequency.

* for architectures which will boot using the muqss cpu scheduler patch, i enable that with a 100hz timer freq instead.

* overcommit is disabled, as well as swap, and i use earlyoom to ensure process destruction proceeds in a controlled manner in event of memory exhaustion.

That's the bulk of it. No real magic involved; just un-fuck-ifying the default kernel config, which is garbage even for server use IMO.

(This is on a 4.x kernel btw, and I have no plans to downgrade to the 5.x series.)

The fact that these some or all of these tweaks aren't done by default would seem, along with other evidence, to support my belief that Linux is actively being sabotaged by people who don't want it to succeed.