On Mon, Jul 20, 2020 at 8:23 AM pmkellly(a)frontier.com
<pmkellly(a)frontier.com> wrote:
Let's talk about zram.
I just got around to figuring out what zram is. I see it's automatically
set up when Anaconda sets up btrfs.
It's setup by zram-generator and zram-generator-defaults being
present, and they're installed by default (or should be) on every
installation image: netintstall, DVD, Live. And whether you do an
automatic or custom installation, regardless of file system. If you do
a custom installation and create a disk based swap partition, you will
have two swaps and the zram-based one will be used with a higher
priority.
First a bit of background all the PCs (Fedora WS) I maintain are
bought
with lots of ram 8GB is the min. I don't think I've ever seen swap move
off zero and no one has reported any sort of slowdowns. Yet we do lots
of memory intensive things. Of course all this is with ext4.
Are you changing /proc/sys/vm/swappiness to reduce or avoid swapping?
The typical case, some swap is used. These are evicted anonymous
pages, and it's more efficient for the kernel to do that for stale
anonymous pages, rather than reclaim (ejecting file pages from memory.
How effective this is does really depend on the workload, but happily
that's the vast majority of the time. And I'm still looking for
workloads that do poorly (I'm sure we'll find some eventually).
Now I see on my test machine (btrfs) that about 24% (2GB) of the 8GB
of
memory (according to monitor) (4GB according to disks) is dedicated to
zram0. I imagine the difference in size reported to due to the
compression used by zram.
Yes but also it's a bit misleading because it's dynamically allocated.
To see how much memory is actually used you need to look at zramctl
output. I'm not actually seeing anywhere in System Monitor where it
suggests how much RAM is being used by the zram device.
First I can't think of any good reason why I should need or want
to have
any of my ram dedicated to swapping or other things that speed up btrfs.
It's not Btrfs specific or related.
Second, a few years back, I looked over some of the compression
algorithms. The probability of loss or corruption was low, but non-zero.
True but if you have corruption resulting from memory problems, that's
bad no matter how much gets corrupted. The memory must be replaced or
you have to figure out the exact location of bad RAM and setup a
kernel exclusion memory map as a boot parameter.
I'm sure they have improved, but I'll bet those probabilities
are still
non-zero. I was taught back in my early years at school that unnecessary
risk is foolish risk. So I've always avoided using compression where
ever I had an option.
The compression itself isn't going to cause corruption. What happens
is more data is effectively corrupted, if there's corruption, due to
the compression. But you don't want corruption happening in the first
place, no matter whether there's compression.
If this is necessary to make btrfs work or get reasonable
performance
from it. That is a strike against btrfs.
If a workload is going to be slower on btrfs, it'll still be slower
whether swaponzram is enabled or not. But if you don't want to use
swaponzram, merely 'touch /etc/systemd/zram-generator.conf' and that
will permanently disable it.
--
Chris Murphy