$ zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 zstd 3G 482.9M 86.7M 91.8M 4 [SWAP]https://linuxblog.io/zswap-better-than-zram/
There is a few other people documenting the same thing if you look around.
As far as Linux and swap goes, very generally speaking: if you don't have a application that specifically advises against having swap you are almost always better off with it.
If you don't end up using it then it costs you almost nothing. If you end up using it then it just makes your system more efficient because you are giving up performance for less used memory to make way for more used memory. Zswap sweetens the deal.
In the distant past having swap on a desktop was irritating because file system operations from nightly crons would end up pushing your applications into swap. Then when you go to use your desktop in the morning it will grid away at the disk until the memory was loaded back into main. This sort of behavior has been mostly solved for a couple decades now, but somehow the idea that "swap is bad and slow" still persists.
When that data doesn't compress well at all, zram is no help and traditional swap-to-storage is a better choice.
And there is a middle-ground option, zswap: swapped out pages will eventually end up on a block device, but are compressed first.
Here's a good summary of what it actually does. https://chrisdown.name/2018/01/02/in-defence-of-swap.html
TL;DR that swap shouldn't be seen as "spare RAM", but a mechanism for paging out anonymous pages, which is desirable in many circumstances in avoiding OOM situations and making memory management work better. It paradoxically typically reduces I/O thrashing.
But why reject taking apparently-free steps to soften the blow?
Is there some advantage in making sure that when the wall is hit, it is hit as hard as it possibly can be?
Edit: seems I got confused there, only frontswap layer was removed, and zcache