> Even something as simple as alt-tabbing lagged for seconds on an overpowered machine.
This may not be KDE's fault; I tracked these kinds of issues down to some bad tunable defaults.
I came up with this:
----
cat /etc/sysctl.d/50-usb-responsiveness.conf
#
# Attempt to keep large USB transfers from locking the system (kswapd0)
#
vm.swappiness = 1
vm.dirty_background_ratio = 5
vm.dirty_ratio = 5
vm.extfrag_threshold = 1000
vm.compaction_proactiveness = 0
vm.vfs_cache_pressure = 200
# FIXME? 64K too big?
vm.page-cluster = 16
----
I have fast everything, NVMe SSD onboard and others in Thunderbolt 4 enclosures and 32GB of RAM on my 12th-Gen i7 with 20 (6+14) cores; there should have been no reason for any stuttering and/or Alt-Tab slowness while doing large file copies and finally got fed up, did some research and experimentation and use the above and it's not happened since.
YMMV, but it's worth a try.
(Oh, and on-topic, I've had to try Wayland (vs. X11) on my KDE desktop 'cause it seems to handle switching monitors when I go from home to work better; jury's still out if I'm keeping it)
You really only need dirty_ratio/bytes and dirty_background_ratio/bytes set to something lower than default. It also makes your progress bars show values closer to reality, especially when copying from fast to slow media.
Some distros already do set lower defaults, e.g. pop os:
> You really only need dirty_ratio/bytes and dirty_background_ratio/bytes set to something lower than default.
The vm.swappiness=1 was very necessary for me as well, and made as much difference as the dirties you'd mentioned.
I usually run Linus' master kernels (as I look for regressions in certain subsystems) and I know there's been some recent changes to the MM subsystem so this may explain some of the necessity for me.
I love(d) it and used it every time I'd go to WF, but TBF I heard about it by "accident" (some small ad somewhere, or maybe it was in the Amazon app?) ... I got the impression Amazon just didn't want to push it much.
Aw ... it was really nice at Whole Paycheck, I'm going to miss it.
Any guesses as to why? Unlike Google Maps Timeline data being subpoenaed, I can't see what LE could use with this (since they have other ways to determine you were at a store), so that can't(?) be the reason why.
Likewise with decorative hedges and other gardenwork; your post brought to mind this one hotel I stay regularly where a hedge is high enough and close enough to the exit that you have to nearly pull into the street to see if there's oncoming cars. I've mentioned to the FD that it's gonna get someone hurt one day, yet they've done nothing about it for years now.
Send certified letters to the owner of the hedge and whatever government agency would enforce rules about road visibility. That puts them "on notice" legally, so that they can be held accountable for not enforcing their rules or taking precautions.
The problem is that they are legally doing nothing wrong. Everything is done according to the rules, so they can't be held accountable for not following them. After all, they are taking all reasonable precautions, what more could be expected of them?
The fact that the situation on the ground isn't safe in practice is irrelevant to the law. Legally the hedge is doing everything, so the blame falls on the driver. At best a "tragic accident" will result in a "recommendation" to whatever board is responsible for the rules to review them.
All that applies for criminal cases, but if a civil lawsuit is started and evidence is presented to the jury that the parties being sued had been warned repeatedly that it would eventually occur, it can be quite spicy.
Which is why if you want to be a bastard, you send it to the owners, the city, and both their insurance agencies.
@Bombcar is correct. Once they've been legally notified of the potential issue, they have increased exposure to civil liability. Their lawyers and insurance company will strongly encourage them to just fix it (assuming it's not a huge cost to trim back the stupid hedge). A registered letter can create enough impetus to overcome organizational inertia. I've seen it happen.
This may not be KDE's fault; I tracked these kinds of issues down to some bad tunable defaults.
I came up with this:
I have fast everything, NVMe SSD onboard and others in Thunderbolt 4 enclosures and 32GB of RAM on my 12th-Gen i7 with 20 (6+14) cores; there should have been no reason for any stuttering and/or Alt-Tab slowness while doing large file copies and finally got fed up, did some research and experimentation and use the above and it's not happened since.YMMV, but it's worth a try.
(Oh, and on-topic, I've had to try Wayland (vs. X11) on my KDE desktop 'cause it seems to handle switching monitors when I go from home to work better; jury's still out if I'm keeping it)
reply