Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1464470 > unrolled thread

[PATCH 0/4] zswap: Optimize compressed pool memory utilization

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 0/4] zswap: Optimize compressed pool memory utilization Srividya Desireddy <srividya.dr@samsung.com> - 2016-08-17 12:10 +0200
    Re: [PATCH 0/4] zswap: Optimize compressed pool memory utilization Pekka Enberg <penberg@kernel.org> - 2016-08-17 14:40 +0200

#1464470 — [PATCH 0/4] zswap: Optimize compressed pool memory utilization

[Multipart message — attachments visible in raw view] — view raw

This series of patches optimize the memory utilized by zswap for storing
the swapped out pages.

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-15% of pages stored in zswap are
duplicates which results in 10-12% more RAM required to store these
duplicate compressed pages. Around 10-20% of pages stored in zswap
are zero-filled pages, but these pages are handled as normal pages by
compressing and allocating memory in the pool.

The following patch-set optimizes memory utilized by zswap by avoiding the
storage of duplicate pages and zero-filled pages in zswap compressed memory
pool.

Patch 1/4: zswap: Share zpool memory of duplicate pages
This patch shares compressed pool memory of the duplicate pages. When a new
page is requested for swap-out to zswap; search for an identical page in
the pages already stored in zswap. If an identical page is found then share
the compressed page data of the identical page with the new page. This
avoids allocation of memory in the compressed pool for a duplicate page.
This feature is tested on devices with 1GB, 2GB and 3GB RAM by executing
performance test at low memory conditions. Around 15-20% of the pages
swapped are duplicate of the pages existing in zswap, resulting in 15%
saving of zswap memory pool when compared to the baseline version.

Test Parameters         Baseline    With patch  Improvement
Total RAM                   955MB       955MB
Available RAM             254MB       269MB       15MB
Avg. App entry time     2.469sec    2.207sec    7%
Avg. App close time     1.151sec    1.085sec    6%
Apps launched in 1sec   5             12             7

There is little overhead in zswap store function due to the search
operation for finding duplicate pages. However, if duplicate page is
found it saves the compression and allocation time of the page. The average
overhead per zswap_frontswap_store() function call in the experimental
device is 9us. There is no overhead in case of zswap_frontswap_load()
operation.

Patch 2/4: zswap: Enable/disable sharing of duplicate pages at runtime
This patch adds a module parameter to enable or disable the sharing of
duplicate zswap pages at runtime.

Patch 3/4: zswap: Zero-filled pages handling
This patch checks if a page to be stored in zswap is a zero-filled page
(i.e. contents of the page are all zeros). If such page is found,
compression and allocation of memory for the compressed page is avoided
and instead the page is just marked as zero-filled page.
Although, compressed size of a zero-filled page using LZO compressor is
very less (52 bytes including zswap_header), this patch saves compression
and allocation time during store operation and decompression time during
zswap load operation for zero-filled pages. Experiments have shown that
around 10-20% of pages stored in zswap are zero-filled.

Patch 4/4: Update document with sharing of duplicate pages feature
In this patch zswap document is updated with information on sharing of
duplicate swap pages feature.

Documentation/vm/zswap.txt |   18 +++
mm/zswap.c                 |  315 +++++++++++++++++++++++++++++++++++++++++---
2 files changed, 316 insertions(+), 17 deletions(-)

[toc] | [next] | [standalone]

#1464553

On Wed, Aug 17, 2016 at 1:03 PM, Srividya Desireddy
<srividya.dr@samsung.com> wrote:
> This series of patches optimize the memory utilized by zswap for storing
> the swapped out pages.
>
> 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-15% of pages stored in zswap are
> duplicates which results in 10-12% more RAM required to store these
> duplicate compressed pages. Around 10-20% of pages stored in zswap
> are zero-filled pages, but these pages are handled as normal pages by
> compressing and allocating memory in the pool.
>
> The following patch-set optimizes memory utilized by zswap by avoiding the
> storage of duplicate pages and zero-filled pages in zswap compressed memory
> pool.
>
> Patch 1/4: zswap: Share zpool memory of duplicate pages
> This patch shares compressed pool memory of the duplicate pages. When a new
> page is requested for swap-out to zswap; search for an identical page in
> the pages already stored in zswap. If an identical page is found then share
> the compressed page data of the identical page with the new page. This
> avoids allocation of memory in the compressed pool for a duplicate page.
> This feature is tested on devices with 1GB, 2GB and 3GB RAM by executing
> performance test at low memory conditions. Around 15-20% of the pages
> swapped are duplicate of the pages existing in zswap, resulting in 15%
> saving of zswap memory pool when compared to the baseline version.
>
> Test Parameters         Baseline    With patch  Improvement
> Total RAM                   955MB       955MB
> Available RAM             254MB       269MB       15MB
> Avg. App entry time     2.469sec    2.207sec    7%
> Avg. App close time     1.151sec    1.085sec    6%
> Apps launched in 1sec   5             12             7
>
> There is little overhead in zswap store function due to the search
> operation for finding duplicate pages. However, if duplicate page is
> found it saves the compression and allocation time of the page. The average
> overhead per zswap_frontswap_store() function call in the experimental
> device is 9us. There is no overhead in case of zswap_frontswap_load()
> operation.
>
> Patch 2/4: zswap: Enable/disable sharing of duplicate pages at runtime
> This patch adds a module parameter to enable or disable the sharing of
> duplicate zswap pages at runtime.
>
> Patch 3/4: zswap: Zero-filled pages handling
> This patch checks if a page to be stored in zswap is a zero-filled page
> (i.e. contents of the page are all zeros). If such page is found,
> compression and allocation of memory for the compressed page is avoided
> and instead the page is just marked as zero-filled page.
> Although, compressed size of a zero-filled page using LZO compressor is
> very less (52 bytes including zswap_header), this patch saves compression
> and allocation time during store operation and decompression time during
> zswap load operation for zero-filled pages. Experiments have shown that
> around 10-20% of pages stored in zswap are zero-filled.

Aren't zero-filled pages already handled by patch 1/4 as their
contents match? So the overall memory saving is 52 bytes?

- Pekka

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web