Does zswap compress pages, that are written to the swap device? Is it eligible to reduce swap IO?
The zswap feature does not normally write to the swap device. It has an allocated space in the system's memory where the pages that are in the process of being swapped are stored. So, a writing to the swap device is completely avoided.
This reduces significantly the system's I/O to the swap device as long as there is available space to store the compressed pages. It writes them back to the backing swap device in the case that the compressed pool is full.
Does zswap compress pages, that are written to the swap device?
No. "During resumed writeback, zswap decompresses the page, adds it back to the swap cache, and schedules writeback into the swap slot that was previously reserved" (http://lwn.net/Articles/537422/)
Is it eligible to reduce swap IO?
Yes, in most cases.
At the LSFMM summit in 2013, there was no compression on pages written to the swap device. But it doesn't sound like there are any technical reasons why not, just that it would increase the complexity.
Hugh [Dickins] added that compression of page cache (file) pages may be appealing, but the filesystem developers do not seem to be that interested in zcache in general. So he agreed that it might make better sense to start with zswap, perhaps adding zcache features over time.
Dan [Magenheimer, zcache hacker] said that he would agree to merging zswap as long as there was an explicit understanding that zswap is not the end of development in this area; there is, he said, a lot more work to be done to gain the full benefits of in-kernel compression. In other words, he would plan to submit patches to increase the functionality of zswap over time.
It sounds like it would make a lot of sense to add this, to save disk space and read/write times, but that it would require some more work and complexity. At a guess, it would take some work to be able to efficiently allocate space on the disk for compressed pages of variable size. (That's just my speculation.)
We might hope to see this in future, but it obviously depends on the efforts of those who would develop on it.
There doesn't seem to be much public discussion about it since 2014. But one way to keep an eye on this might be to monitor the commits made to mm/zswap.c in the kernel.