On Mon, Jun 21, 2021 at 10:51 AM Barry Scott <ba...@barrys-emacs.org> wrote: > > The SSDs are a lot slower than compressing a page into RAM. > > There was extensive discussion on the Fedora Devel list when this change was > proposed. > > Personally I was convinced that this change is an improvement for any system > that is under > memory pressure. I'm not going to try to recall the discussion as I may get > some details > wrong.
At a high level, zram is a ram disk that has transparent compression. You can format it with mkswap or any other file system, use it as a block device. But nuts and bolts memory management, reclaim, paging in and out, it's quite complicated. There's work happening since kernel 5.8 to make swap a lot more effective. And on going work to make mm and zswap do the right thing. And zswap is a different thing altogether, it's a front cache that uses a compressed memory pool as a cache for a conventional swap file or partition. And it works on an least recently used basis. So it has a way of determining what's stale and pushing that out to disk, while keeping recent things in the (memory) cache. In this case we don't have the concerns with priority inversions that can happen when a particular sequence of events happens: 1. zram based swap has higher priority 2. conventional swap has lower priority 3. early workloads fill up zram with stale things not used again later 4. the general workload ends up using disk based swap So this is not really any worse than before at this point except it is consuming some memory, just to keep stale things available in case they get used. And if they do get used, it'll be quite fast. That's not obviously a bad thing, except it is taking a limited resource off the table. That's atypical for desktop workloads. But you can imagine that the more resources a system has the more variable the workload can be, and you could see early swap fill up a zram device, and then it can't be used again until the programs that created those anonymous pages are quit, in the extreme case. Anyway, how to optimize was the whole point of moving to zram based swap. And it won't stop there. There is still more work happening to get zswap cgroups aware. Neither zram nor zswap are at the moment so for resource control purposes, we actually need a plain swap partition or swap file, it can't even be on dm-crypt at the moment. And one of the nice things about zram based swap is, it's volatile, so we have less security concerns about questionable things ending up on persistent storage that don't even go in a user's ~/home. Anything could be evicted to swap. > I switched it on in F33 and have for over a year seen no down side for my > work loads. > My work loads are file+email server, firewall, KDE desktops, Kodi music > server. > > At my work once we get on to Centos 8 I'm planning to performance test with > zram swap. > We have a work load that is very sensitive to disk I/O spikes and there is > some sad > code that uses swap for 10s to 15s every 20mins of so that I want to make go > away. > We have RAID-10 SSD where we see issues. With centos 8 kernels you'd probably use zram based swap because it's more mature in the older kernels. If you are able to use an elrepo kernel you could try changing nothing else and see if the kernel 5.8+ changes help your workload all by themselves. And if not you could look at either zram based swap or zswap. -- Chris Murphy _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
