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: <571DC72F.3030503@suse.cz>
Date:	Mon, 25 Apr 2016 09:28:47 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Vitaly Wool <vitalywool@...il.com>
Cc:	Linux-MM <linux-mm@...ck.org>, linux-kernel@...r.kernel.org,
	Seth Jennings <sjenning@...hat.com>,
	Dan Streetman <ddstreet@...e.org>
Subject: Re: [PATCH v2] z3fold: the 3-fold allocator for compressed pages

On 04/22/2016 01:22 AM, Andrew Morton wrote:
> On Tue, 19 Apr 2016 11:48:45 +0200 Vitaly Wool <vitalywool@...il.com> wrote:
>
>> This patch introduces z3fold, a special purpose allocator for storing
>> compressed pages. It is designed to store up to three compressed pages per
>> physical page. It is a ZBUD derivative which allows for higher compression
>> ratio keeping the simplicity and determinism of its predecessor.
>>
>> The main differences between z3fold and zbud are:
>> * unlike zbud, z3fold allows for up to PAGE_SIZE allocations
>> * z3fold can hold up to 3 compressed pages in its page
>>
>> This patch comes as a follow-up to the discussions at the Embedded Linux
>> Conference in San-Diego related to the talk [1]. The outcome of these
>> discussions was that it would be good to have a compressed page allocator
>> as stable and deterministic as zbud with with higher compression ratio.
>>
>> To keep the determinism and simplicity, z3fold, just like zbud, always
>> stores an integral number of compressed pages per page, but it can store
>> up to 3 pages unlike zbud which can store at most 2. Therefore the
>> compression ratio goes to around 2.5x while zbud's one is around 1.7x.
>>
>> The patch is based on the latest linux.git tree.
>>
>> This version of the patch has updates related to various concurrency fixes
>> made after intensive testing on SMP/HMP platforms.
>>
>> [1]https://openiotelc2016.sched.org/event/6DAC/swapping-and-embedded-compression-relieves-the-pressure-vitaly-wool-softprise-consulting-ou
>>
>
> So...  why don't we just replace zbud with z3fold?  (Update the changelog
> to answer this rather obvious question, please!)

There was discussion between Seth and Vitaly on v1. Without me knowing 
the details myself, it looked like Seth's objections were addressed, but 
then the thread died. I think there should first be a more clear answer 
from Seth whether z3fold really looks like a clear win (i.e. not 
workload-dependent) over zbud, in which case zbud could be extended?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ