Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753614AbcDYH2v (ORCPT ); Mon, 25 Apr 2016 03:28:51 -0400 Received: from mx2.suse.de ([195.135.220.15]:47205 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751771AbcDYH2u (ORCPT ); Mon, 25 Apr 2016 03:28:50 -0400 Subject: Re: [PATCH v2] z3fold: the 3-fold allocator for compressed pages To: Andrew Morton , Vitaly Wool References: <5715FEFD.9010001@gmail.com> <20160421162210.f4a50b74bc6ce886ac8c8e4e@linux-foundation.org> Cc: Linux-MM , linux-kernel@vger.kernel.org, Seth Jennings , Dan Streetman From: Vlastimil Babka Message-ID: <571DC72F.3030503@suse.cz> Date: Mon, 25 Apr 2016 09:28:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160421162210.f4a50b74bc6ce886ac8c8e4e@linux-foundation.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2024 Lines: 38 On 04/22/2016 01:22 AM, Andrew Morton wrote: > On Tue, 19 Apr 2016 11:48:45 +0200 Vitaly Wool 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?