linux-kernel - Re: [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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAOJsxLEQsnnWjNOcVDNjL0J5hCe1TKxh48AXRD06kJRL62gopg@mail.gmail.com>
Date:	Wed, 17 Aug 2016 15:32:36 +0300
From:	Pekka Enberg <penberg@...nel.org>
To:	srividya.dr@...sung.com
Cc:	sjenning@...hat.com, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	LKML <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: Re: [PATCH 3/4] zswap: Zero-filled pages handling

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