Is the High Price of RAM a Good Opportunity to Promote FreeBSD?

FreeBSD, thanks to its excellent Virtual Memory System, optimally uses any swap memory you set up (unlike Linux or Windows). You can, for example, set up 8-16 GB of swap memory on a separate disk (or even on the same one), and you will be able to execute a ton of memory-demanding software (your browser with many tabs open, your graphical text editor, spreadsheet, music player) at the same time on your favorite memory-heavy desktop environment (Plasma, Gnome) and even add a couple of Windows or Linux VMs on VirtualBox to the mix, all of this with only 16 GB of RAM. The system will not freeze. Some windows may take a couple of seconds to respond while FreeBSD is restoring their memory from swap, but that's it. If you are using Plasma, as is my case, the window will render in black and white while it's "waking up." I don't know how this works on other DEs. All this describes my experience.
 
When the system begins swapping, having too much swap makes it worse as the system becomes unresponsive. 2GB is the maximum for me. Wish FreeBSD supported Linux's zram to get away with swap partitions. I'm running Debian with OpenZFS on a Raspberry Pi with 8GB RAM using zram with no issues.
 
having too much swap makes it worse as the system becomes unresponsive
Well, this never happened to me. What happens to me is what I described in the original post. I must be a Martian. It was a bad idea to start this thread. It's making me sad to see how wrong I was and how little love there's for the VMS.
 
Well, this never happened to me. What happens to me is what I described in the original post. I must be a Martian. It was a bad idea to start this thread. It's making me sad to see how wrong I was and how little love there's for the VMS.
Life's too short to be sad about stuff like this. Regret only what you didn't do. Let others chime in on their experience with swap on FreeBSD.
 
From my observation (with no measurement) FreeBSD indeed behaves best of the main OSes when there is serious RAM shortage. It just seems to be smarter about when to page out (as opposed to dropping readonly pages) and what to page out.

Linux tends to shoot itself in the foot with aggressively dropping readonly pages instead of paging out. That leads to C, C++ and Rust code not being available when needed. The swappiness parameter doesn't fully help. In addition the kernel OOM killer is too aggressive and gives up too early before swap is full given that SSDs give back pages reasonably fast now. And don't get me started on that piece of shit systemd OOM killer they put in front of the kernel one.
 
Wish FreeBSD supported Linux's zram to get away with swap partitions. I'm running Debian with OpenZFS on a Raspberry Pi with 8GB RAM using zram with no issues.
gotta agree with you here, zram support on FreeBSD would be great, or at least zswap
no one seems to bother with it however, i'd guess it's because it's mainly used on servers and those already have enough ram

From my observation (with no measurement) FreeBSD indeed behaves best of the main OSes when there is serious RAM shortage. It just seems to be smarter about when to page out (as opposed to dropping readonly pages) and what to page out.
that's what i've felt while using it as well to be honest, its performance is a lot more consistent

And don't get me started on that piece of shit systemd OOM killer they put in front of the kernel one.
thank god i don't use systemd anymore : )
 
This is a great opportunity for the project research into dynamic memory compression; something macOS has had since Mavericks. No need for slow SSD swapping.
 
My computer at this exact moment:

Screenshot_20260114_070003.png


And it's running absolutely SMOOTHLY. I don't feel any delay whatsoever. For me, it's like magic. I had never experienced this on Windows or Linux. I guess I'm just lucky.
 
I hate to say this, but reality is, Windows should perform better than either Linux or FreeBSD for desktop usage.
NT is nothing to scoff at, and Microsoft has been a desktop system leader for 30 years, pouring billions of $ into the development along.

For example, LTSC versions of Windows, or Server edition with no daemons running, should have less resident memory usage, boot faster, and have smoother UI than any X11 based system that has same levels of functionality - all the automagic desktop stuff.
 
I hate to say this, but reality is, Windows should perform better than either Linux or FreeBSD for desktop usage.
NT is nothing to scoff at, and Microsoft has been a desktop system leader for 30 years, pouring billions of $ into the development along.

For example, LTSC versions of Windows, or Server edition with no daemons running, should have less resident memory usage, boot faster, and have smoother UI than any X11 based system that has same levels of functionality - all the automagic desktop stuff.

Well, all benchmarks recently put Linux as faster than Windows.

They look pretty painted into a corner, performance-wise.
 
Memory compression doesn't seem to work all that well. Too many kinds of data that doesn't compress.
what could some of those kinds be, may i ask? i thought data was data

Well, all benchmarks recently put Linux as faster than Windows.

They look pretty painted into a corner, performance-wise.
yeah i think the argument of investing billions of dollars into something barely means anything at this point
i've seen a lot of people say Linux ran faster than Windows 11, and i myself had the same experience

also not many people will even know what the LTSC version of windows is, the overwhelming majority of them will just stick to the original
 
what could some of those kinds be, may i ask? i thought data was data

When it comes to needing lots of RAM on consumer machine audio work comes to mind, Audio data doesn't compress with universal compression algorithms, even zstd only gets it down to 90% of the original size. A specialized algorithm like flac compresses to 50%, but is way too computationally expensive and doesn't appear in OS kernels. This is a problem for music producers who use many tracks of sampled instruments. There are one of the main buyer groups of high-memory Macs (as much as that hurts).

The situation is not different for image and video data.

Text can be compressed well of course.

Compiled code compresses well, but in most cases compiled code is mapped from disk read-only and hence is not subject to paging and in-kernel compression. Java code would be different of course.

Keep in mind that trying to and failing to compress just puts extra load on the CPU. That is why I am skeptical about in-kernel compression when seen from a high-level. I would prefer a control switch to only turn it on when I figure it will pay off.
 
so that's another reason why not to implement it, makes sense now
those are probably the ones that take the most ram space as well (especially video data), so compressing the small portions wouldn't be worth the CPU burden indeed
 
yeah i think the argument of investing billions of dollars into something barely means anything at this point
i've seen a lot of people say Linux ran faster than Windows 11, and i myself had the same experience

What I have not seen is benchmarks themed "what happens when you run out of RAM?". The basics wouldn't be too difficult to do, but there are so many variables to consider once you get down to metal. For example, how does it score if one OS already killed a process and the other one did not? Did that OS do a good job or not? Obviously if the other OS managed to pull through with all processes unkilled it would win this benchmark. But what if it becomes unresponsive for 25 minutes while doing so? Is that still "better"?

As I said from anecdotical evidence my eyes absorbed in the last decades FreeBSD is really good at pulling through without killing and excessive slowdowns. Just good decision making when paging.
 
Keep in mind that trying to and failing to compress just puts extra load on the CPU
Normally, the performance of modern CPUs can offset the reduction in needed bandwith. I once ran the test, where the total time for reading/writing was about equal. What was used up in the compression/decompression was gained by shorter I/O. That was some 20 years ago, I think today you have an advantage.

FreeBSD does one thing Linux does not - it pretty heavily pushes memory trough the laundry. Dirty pages get written to swap when time allows (and they have not been touched for a bit), but are kept in memory. When memory pressure sets in, these can be reclaimed at once, oldest first. Thats why the system still is very responsive when swap is already filled a bit - it does not do any swapping at that point. More precisely, paging that is. Swapping is when complete processes go out for lunch. These now clean pages might even be stolen by the disk cache, giving you more cache memory. When all of that fails, the ARC will get pressure to release some memory - but untill then there is little you would notice.

Only when you start to touch that paged out memory again, the speed penalty is visible.

And you might try to swap on a zvol that is compressed.
 
AI demand has driven dram prices up 10x from a few years ago.

I recently paid $389 USD 32gb of DDR5 for my grandsons new Win11 machine.

Nvidia gpus are similarly inflated again due to extreme demand.

My old Micron stock languished at $8 per share and is now $308 today.
 
Back
Top