On 16.06.22 18:40, Yeongjin Kwon wrote: > Hi, > Hi > As I understand it, zswap currently handles same filled pages by > storing them uncompressed and then copying them out when they are What I get from the doc is: " Some of the pages in zswap are same-value filled pages (i.e. contents of the page have same value or repetitive pattern). These pages include zero-filled pages and they are handled differently. During store operation, a page is checked if it is a same-value filled page before compressing it. If true, the compressed length of the page is set to zero and the pattern or same-filled value is stored. " And staring at the code (zswap_is_page_same_filled()) all it does is checking for a repetitive pattern sizeof(unsigned long) pattern and storing that pattern instead of compressing. Which is an optimization for compression, not deduplication of pages. If a page is filled with 0xFF, just store "page is filled with 0xFF" instead of a pointer to a compressed chunk stating the same. > loaded. A possible alternative could be to have same filled pages that > get swapped out mapped to the page stored in zswap as copy on write in > the page table, instead of being marked as swapped out. Then reads zswap really feels like the wrong place to do something like that. Its job is not memory deduplication, it's compression. We do have KSM for deduplication. > from the "swapped out" page will just read the underlying page stored > in zswap, and the stored page will only be truly loaded/copied out > when it is written to. This is similar in concept to the copy on write > mechanism the kernel has for forking processes. Would this be worth > implementing? I am largely unfamiliar with kernel development. This is Please take a look at KSM. And maybe how KSM and similar memory deduplication techniques provide a steady stream of work for security researchers. :) -- Thanks, David / dhildenb
