Lemmy feature request: Show my negative “karma” in my profile page. You can make it opt-in if you must.
It would be a cool if you report back in a separate post if you discovered anything interesting. It’s not like we’re overwhelmed by too much activity here.
Also, while I think it should be obvious, but I forgot to clarify that if you’re inheriting from a profile with codegen-units = 1, then you need to set that explicitly to a higher value in the inheriting profile.
Make sure you’re using a fast linker. Although I think lld is the default now, so that should be less of a concern these days. But see if mold or wild would help.
More relevantly, you should be using cranelift for codegen in dev builds.
If you have codegen-units = 1 in your release profile, make sure you have a separate dev profile that doesn’t.
If you still experience decapitating slowness (doubtful), and it’s actually the rust compiler being slow (super doubtful), you can try the parallel frontend. Apparently there are almost™ no bugs left in its implementation (It’s one of the project priorities now).
Needless to say, but you should be checking your --timings to really know what’s going on.
LRU inversion: the problem with not caring about it is that it’s not a visible problem until it very suddenly is. Your system will not gradually degrade but very suddenly and unpredictably hit a wall that it cannot get itself over.
All this talk just confirms my feelings that there is a general lack of understanding of actual modern workloads.
RAM (normal w/wo zram) doesn’t get full, then stay full forever in real workloads. Not only is that not realistic at the “opened apps”/“running processes” level, it’s not real at the heap allocation level within tasks within processes. And this is much more pronounced with code written in modern languages like Rust and some styles of C++. Modern heap allocators batch and cache (primarily to help with performance). But still, A LOT of memory is getting allocated and deallocated all the time, even from the kernel’s PoV.
LRU itself is an imperfect approximation, not a goal. In the setup described in my other comment (fast SSD swap storages only used sparingly most of the time), so called LRU inversion gets auto-cancelled relatively quickly, as free space in RAM(+zram) gets available all the time, and some “LRU-hot” pages in SSD swap turn out to be actually cold, and those ones are the only ones that actually stay there.
This is why, I would imagine a lot of fake scenarios, and “benchmarks” based on them, may fail to replicate the practical reality of many (overall system) use-cases.
More tangentially, the oversized concern for file caching pages also points to specific aligned use-cases in mind, as if everyone is running DB-centric workloads or something.
This is not a good thing btw. Any unused anonymous page takes up space that could instead be used for file-backed pages that make your system faster.
Can you expand here. I think my attempt at brevity in this part wasn’t helpful.
Swap is not tiered storage!
I meant tiered with priorities only, yes.
Cool tech but it’s dead and was quite niche even when it was alive.
We are not talking about the original purpose of Optane as supported on Windows. It’s just a (perhaps somewhat outdated) example of a storage device “smaller but faster than your average SSD storage”, which is very much not did tech.
Not a thing you actually want to use for swap
Depends on the use-case. But yes, this can also be used as the fastest disk tier/priority of normal swap devices, which is why I mentioned both.
This makes no sense at all unless you are extremely space-constrained on the NVMe and absolutely must not OOM – even if progress stalls to an absolute crawl.
Why would you want to see killed processes when you go back to your workstation, in the 1/10000th scenario where something runs amok pushing memory usage to unexpected high levels? When you can simply investigate the reason behind the rare occurrence, then move all the pages off the slowest devices immediately with swapoff?
It was just an example of a “smaller+faster than your average SSD”.
and I was mentioning something similar to my setup instead of an imaginary use-case.
Alright, I will only reply to you, since you raised a fair question.
First of all, I must admit that I thought what was linked was an earlier similar writing, but the general theme is still the same.
The problem with the writing is that it focuses on use-cases like Android and some servers, but doesn’t take into account other use-cases. It also seems to come with the assumption that setup is done by the distributor only, or if it’s done by the user, it’s a configure-and-forget situation.
What he represents is:
Now let’s look at a possible modern workstation setup:
This last point in particular should make it clear why his “imagination” was rather limited in his LRU inversion section.
If you’re going to hand out free advice, at least make sure the advice is worth the price of admission.
This is very ironic, considering your comment is a mix of straw man and wrong.
It’s shit info. zram is actually better, more so with high ram size+high usage situations.
Oh, you wrote “easy” not “early” in OP. In any case, this looks stupid. But to each their own, I guess.
Why do you think 32GiB is special compared to 16GiB?
And wtf is EasyOOM?
You maximize the usefulness of zram by actually increasing sappiness, and giving zram devices high priority. e.g.
sysctl vm.swappiness=100
for i in {1..8}; do
swapon /dev/zram${i} -p 32767
done
Then you enable other swap devices with lower priority.
This is the way regardless of how much RAM you have. I mean, it may be pointless if you never ever exceed, let’s say 10/32GiB (including caching). But it still wouldn’t be harmful in any way.
zram makes sense if you do not have swap.
wrong.
zswap is probably enabled by default in most distros.
wrong
You should look up the genetic fallacy. And using phrases like “hand-craft code” make you look stupid.
If you’re posting from Desktop Linux, your comment utilized at least 10 liberally licensed libraries. And that’s before it got into the wire. GPL packages are a MINORITY, not a majority with exceptions.
There are a lot less GPL projects in your system than you might think. Your core system is already filled with liberally licensed libraries and programs. Case in point, since you talked about rust rewrites, original sudo is not GPL software.
Did you ask an LLM to write a comment full of cliches?
You are in a thread where a user is having a problem because of the push for flatpaks, and because of some distros like Fedora crippling their packages and providing objectively worse alternatives on purpose (because they don’t want to risk RH IBM getting sued). If the user was using some sane community distro like Arch, the user would have never come to realize that such unnecessary issues even exist.
As for flatpak hate specifically, see my ramblings here.
Users are better off using a “freeworld” ffmpeg package, or not using Fedora at all. The cisco decoder is shit.
your life will be better if you stop using both flatpaks and openh264.
I don’t watch YouTube at all outside of a couple of 70+ years old personalities who do some weekly commentary (not in English or tech related).
Zero search/feed/side-bar “consooming”.
Slop-sumption is not unavoidable. You just need to learn how to value your time, and develop a simple objectivity/knowledgeability filter.