From: "Srividya Desireddy" <srividya.dr@samsung.com>
To: penberg@kernel.org
Cc: "Srividya Desireddy" <srividya.dr@samsung.com>,
sjenning@redhat.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
"Dinakar Reddy Pathireddy" <dinakar.p@samsung.com>,
"SUNEEL KUMAR SURIMANI" <suneel@samsung.com>,
김주훈 <juhunkim@samsung.com>
Subject: [PATCH 0/4] zswap: Optimize compressed pool memory utilization
Date: Fri, 19 Aug 2016 05:34:30 +0000 [thread overview]
Message-ID: <1341407574.7551.1471584870761.JavaMail.weblogic@epwas3p2> (raw)
In-Reply-To: CGME20160819053430epcms5p1287860bbf6376d25e569e5069fae0759@epcms5p1
[-- Attachment #1: Type: text/plain, Size: 4082 bytes --]
On 17 August 2016 at 18:08, Pekka Enberg <penberg@kernel.org> wrote:
> 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
Thanks for the quick reply.
Zero-filled pages can also be handled by patch 1/4. It performs
searching of a duplicate page among existing stored pages in zswap.
Its been observed that average search time to identify duplicate zero
filled pages(using patch 1/4) is almost thrice compared to checking
all pages for zero-filled.
Also, in case of patch 1/4, the zswap_frontswap_load() operation requires
the compressed zero-filled page to be decompressed. zswap_frontswap_load()
function in patch 3/4 just fills the page with zeros while loading a
zero-filled page and is faster than decompression.
- Srividya
next parent reply other threads:[~2016-08-19 5:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20160819053430epcms5p1287860bbf6376d25e569e5069fae0759@epcms5p1>
2016-08-19 5:34 ` Srividya Desireddy [this message]
[not found] <CGME20170216130523epcms5p880c2d88837293a158f9c69597082f969@epcms5p8>
2017-02-16 13:05 ` [PATCH 0/4] zswap: Optimize compressed pool memory utilization Srividya Desireddy
[not found] <CGME20160817100328epcms5p2521a3ce1725a2cc4f2da82e2e1b79f33@epcms5p2>
2016-08-17 10:03 ` Srividya Desireddy
2016-08-17 12:38 ` Pekka Enberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1341407574.7551.1471584870761.JavaMail.weblogic@epwas3p2 \
--to=srividya.dr@samsung.com \
--cc=dinakar.p@samsung.com \
--cc=juhunkim@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=sjenning@redhat.com \
--cc=suneel@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).