Skip to content
  • Srividya Desireddy's avatar
    zswap: same-filled pages handling · a85f878b
    Srividya Desireddy authored
    Zswap is a cache which compresses the pages that are being swapped out
    and stores them into a dynamically allocated RAM-based memory pool.
    Experiments have shown that around 10-20% of pages stored in zswap are
    same-filled pages (i.e.  contents of the page are all same), but these
    pages are handled as normal pages by compressing and allocating memory
    in the pool.
    
    This patch adds a check in zswap_frontswap_store() to identify
    same-filled page before compression of the page.  If the page is a
    same-filled page, set zswap_entry.length to zero, save the same-filled
    value and skip the compression of the page and alloction of memory in
    zpool.  In zswap_frontswap_load(), check if value of zswap_entry.length
    is zero corresponding to the page to be loaded.  If zswap_entry.length
    is zero, fill the page with same-filled value.  This saves the
    decompression time during load.
    
    On a ARM Quad Core 32-bit device with 1.5GB RAM by launching and
    relaunching different applications, out of ~64000 pages stored in zswap,
    ~11000 pages were same-value filled pages (including zero-filled pages)
    and ~9000 pages were zero-filled pages.
    
    An average of 17% of pages(including zero-filled pages) in zswap are
    same-value filled pages and 14% pages are zero-filled pages.  An average
    of 3% of pages are same-filled non-zero pages.
    
    The below table shows the execution time profiling with the patch.
    
                                Baseline    With patch  % Improvement
      -----------------------------------------------------------------
      *Zswap Store Time           26.5ms       18ms          32%
       (of same value pages)
      *Zswap Load Time
       (of same value pages)      25.5ms       13ms          49%
      -----------------------------------------------------------------
    
    On Ubuntu PC with 2GB RAM, while executing kernel build and other test
    scripts and running multimedia applications, out of 360000 pages stored
    in zswap 78000(~22%) of pages were found to be same-value filled pages
    (including zero-filled pages) and 64000(~17%) are zero-filled pages.  So
    an average of %5 of pages are same-filled non-zero pages.
    
    The below table shows the execution time profiling with the patch.
    
                                Baseline    With patch  % Improvement
      -----------------------------------------------------------------
      *Zswap Store Time           91ms        74ms           19%
       (of same value pages)
      *Zswap Load Time            50ms        7.5ms          85%
       (of same value pages)
      -----------------------------------------------------------------
    
    *The execution times may vary with test device used.
    
    Dan said:
    
    : I did test this patch out this week, and I added some instrumentation to
    : check the performance impact, and tested with a small program to try to
    : check the best and worst cases.
    :
    : When doing a lot of swap where all (or almost all) pages are same-value, I
    : found this patch does save both time and space, significantly.  The exact
    : improvement in time and space depends on which compressor is being used,
    : but roughly agrees with the numbers you listed.
    :
    : In the worst case situation, where all (or almost all) pages have the
    : same-value *except* the final long (meaning, zswap will check each long on
    : the entire page but then still have to pass the page to the compressor),
    : the same-value check is around 10-15% of the total time spent in
    : zswap_frontswap_store().  That's a not-insignificant amount of time, but
    : it's not huge.  Considering that most systems will probably be swapping
    : pages that aren't similar to the worst case (although I don't have any
    : data to know that), I'd say the improvement is worth the possible
    : worst-case performance impact.
    
    [srividya.dr@samsung.com: add memset_l instead of for loop]
    Link: http://lkml.kernel.org/r/20171018104832epcms5p1b2232e2236258de3d03d1344dde9fce0@epcms5p1
    
    
    Signed-off-by: default avatarSrividya Desireddy <srividya.dr@samsung.com>
    Acked-by: default avatarDan Streetman <ddstreet@ieee.org>
    Cc: Seth Jennings <sjenning@redhat.com>
    Cc: Pekka Enberg <penberg@kernel.org>
    Cc: Dinakar Reddy Pathireddy <dinakar.p@samsung.com>
    Cc: SHARAN ALLUR <sharan.allur@samsung.com>
    Cc: RAJIB BASU <rajib.basu@samsung.com>
    Cc: JUHUN KIM <juhunkim@samsung.com>
    Cc: Matthew Wilcox <willy@infradead.org>
    Cc: Timofey Titovets <nefelim4ag@gmail.com>
    Cc: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    a85f878b