On Mon, Jul 20, 2020 at 8:23 AM pmkellly@xxxxxxxxxxxx <pmkellly@xxxxxxxxxxxx> 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 _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
