> On Sat, Jun 6, 2020 at 10:00 AM Richard W.M. Jones <rjones(a)redhat.com> wrote: > > (ZRAM) > Compression is intrinsic to just the /dev/zram device. The swap code > doesn't share pages between swap devices. The higher priority device > is favored first until full. Once full, pages don't go through the > zram module, thus are not compressed, on their way to the > swap-on-disk. > > (ZSWAP) > So yeah, the swap-on-disk scenario might be better suited to a > generator that could use zswap instead, which uses an existing swap > partition and adds a write back cache (zpool) rather than a separate > device. I'm pretty sure (not 100%) that cached page are decompressed > on their way to the swap device. Also, the zpool memory cache is > preallocated, unlike zram devices. > > (I am not going to envy any who decide to implement zswap on a system > with ZFS. Wait wait wait, which zpool are you talking about?!) So, I am testing ZRAM right now (as per your advice in another thread). All well so far, however reading this makes me think I gonna stumble upon a point where ZSRAM will be a better fit. You see, the idea of ZRAM and ZSWAP is improving low-memory situation. This is especially relevant for small amount of RAM, like your Raspberry example. In such situation if you, for example, open a lot of tabs in a browser, you may easily get to a point where even ZRAM is exhausted. Now, had you additionally a SWAP device, it would be no problem, the data would simply spill over to SWAP. Yes, SWAP is slow (well, it is on HDD at least). But consider this: in this workload , you most likely not gonna touch older of browser tabs for quite some time, so the slowness won't hurt you. My point is that we still need disk swap. And if we have disk swap, we'd want to move into SWAP the most unused memory pages. Which is how it works with ZSWAP. But not how it works with ZRAM (in which case, as you noted, once it's full, all new data would simply go past ZRAM into disk SWAP) --------- Now, I love the idea of using either ZRAM or ZSWAP. But to consider which one of them do we want, I think we would need to discuss first: do we really want to get rid of disk swap? Hibernation being discussed somewhere in this thread is another point. I personally don't like idea of removing disk swap. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
