> yes it shows the bottleneck but it is quite artificial. Read data is > usually processed and/or written back and that changes the picture a > lot. Apologies for reviving an ancient thread (and apologies in advance for my lack of knowledge on how mailing lists work), but I'd like to offer up another reason why merging this might be a good idea. >From what I understand, zswap runs its compression on the same kswapd thread, limiting it to a single thread for compression. Given enough processing power, zswap can get great throughput using heavier compression algorithms like zstd, but this is currently greatly limited by the lack of threading. People on other sites have claimed applying this patchset greatly improved zswap performance on their systems even for lighter compression algorithms. For me personally I currently have a swap-heavy zswap-enabled server with a single-threaded kswapd0 consuming 100% CPU constantly, and performance is suffering because of it. The server has 32 cores sitting mostly idle that I'd love to put to zswap work. This setup could be considered a corner case, but it's definitely a production workload that would greatly benefit from this change. -- Sebastiaan Meijer
