linux-kernel - [PATCH 3/4] zswap: Zero-filled pages handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-id: <431871851.13330.1471613444880.JavaMail.weblogic@epwas3p2>
Date:   Fri, 19 Aug 2016 13:30:44 +0000
From:   Srividya Desireddy <srividya.dr@...sung.com>
To:     penberg@...nel.org
Cc:     Srividya Desireddy <srividya.dr@...sung.com>,
        sjenning@...hat.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Dinakar Reddy Pathireddy 
        <dinakar.p@...sung.com>,
        샤란 <sharan.allur@...sung.com>,
        SUNEEL KUMAR SURIMANI <suneel@...sung.com>,
        김주훈 <juhunkim@...sung.com>
Subject: [PATCH 3/4] zswap: Zero-filled pages handling


On 17 August 2016 at 18:02, Pekka Enberg <penberg@...nel.org> wrote:
> On Wed, Aug 17, 2016 at 1:18 PM, Srividya Desireddy
> <srividya.dr@...sung.com> wrote:
>>> This patch adds a check in zswap_frontswap_store() to identify zero-filled
>>> page before compression of the page. If the page is a zero-filled page, set
>>> zswap_entry.zeroflag and skip the compression of the page and alloction
>>> of memory in zpool. In zswap_frontswap_load(), check if the zeroflag is
>>> set for the page in zswap_entry. If the flag is set, memset the page with
>>> zero. This saves the decompression time during load.
>>>
>>> The overall overhead caused due to zero-filled page check is very minimal
>>> when compared to the time saved by avoiding compression and allocation in
>>> case of zero-filled pages. The load time of a zero-filled page is reduced
>>> by 80% when compared to baseline.
>
> On Wed, Aug 17, 2016 at 3:25 PM, Pekka Enberg <penberg@...nel.org> wrote:
>> AFAICT, that's an overall improvement only if there are a lot of
>> zero-filled pages because it's just overhead for pages that we *need*
>> to compress, no? So I suppose the question is, are there a lot of
>> zero-filled pages that we need to swap and why is that the case?
>
> I suppose reading your cover letter would have been helpful before
> sending out my email:
>
> "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."
>
> But I still don't understand why we have zero-filled pages that we are
> swapping out.
>
> - Pekka

Zero-filled pages exists in memory because applications may be
initializing the allocated pages with zeros and not using them; or
the actual content written to the memory pages during execution 
itself is zeros.
The existing page reclamation path in kernel does not check for
zero-filled pages in the anonymous LRU lists before swapping out.

- Srividya