I now understand why we have multi-core processors. So that a process that dun shit the bed doesn't hog the whole fucking CPU! Of course at the expense of "yeah our shitty software can hog the CPU no problem, there's now several cores anyway". Hardware solving the crap that software presents, yet again.

@theKarlisK Do you know Wirth's law? "Software is getting slower more rapidly than hardware becomes faster."
It's from 1995. This phenomenom is much older than 7-10 years.

Not true. Cpu hungry processes can perfectly run on a single core single thread cpu along with other processes w/o restricting them from cpu time. That's what task scheduler is for [multi-process OS component] :) and that's what sysadmins amd a ´nice´ command are for!

On a single thread setup processes run consurrently.
On a multithread setup processes run concurrentlt and in parallel.

Unless this post was a joke and I didn't get it and took it too seriously again... 😁

@netikras Now that you mention it.. indeed, but the issue is when a process hogs up the whole core and doesn't allow other processes to take a slice of it anymore. Every so often I see this on the old single-core desktops I used as auxiliary workstation machines on my desk (big huge Windows machine in the middle to control 2 auxiliary ones that run Linux/BSD for better server management than WSL currently can provide etc). Both single core, and so often it locks up... As if the CPU is busy churning through one little thing before it can do anything else, sometimes for extended periods of time. All my other machines have multiple cores of course but on those single-core machines it's really noticeable. It's usable for sure so I think I've configured them somewhat decently (given their age) but.. it does lag at times, especially with Bluetooth. Which kind of makes me think that (combined with many other issues) its Linux implementation is terrible.

Find the processes that are hogging your cpu, find what states are they in the most. Either ´ps aux´ or ´while :; do cat /proc/<pid>/stat ; done | grep State´. Or even ´strace -fvpTc <pid>´ [params might differ in bsd, I'm writing them from my memory]. I can almost bet that these processes are hogging your cpu due to IOW and they spend lots of time in D states.

As for bluetooth, it's a nasty buggar. It raises your system's load avg [meaning hi iow%] while it's scanning for devices. And some clients are constantly scanning [that's the reason my lappy's battery used to drain very quickly and the system was sluggish.. An i7 skylake setup. Lagged by a bluetooth... Pathetic!]

yes, if your system's suffering from D state processes, single core cpu will be indeed blocked as task scheduler cannot interrupt syscalls which are unintertuptible by design. Multithreaded systems, since they run processes in parallel, will still exhibit slowdowns, but not as strongly as singlethreaded ones.

Do some analysis. It's very likely some i/o device. ´vmstat´ will show you iow, ´dmesg´ will tell you whether any modules are buggy and do lock your cpus for >60sec. [BUG!!! Cpu lockup detected -- error in dmesg looks smth like that when you have driver issues]

>hardware solving flaws in software

Shame we can't do the opposite, huh?

@Parzi true.. especially high-profile vulnerabilities like Spectre and Meltdown.. terrifying 😰