Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754843AbcDYOyy (ORCPT ); Mon, 25 Apr 2016 10:54:54 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:32927 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752601AbcDYOyw (ORCPT ); Mon, 25 Apr 2016 10:54:52 -0400 MIME-Version: 1.0 In-Reply-To: <571DC72F.3030503@suse.cz> References: <5715FEFD.9010001@gmail.com> <20160421162210.f4a50b74bc6ce886ac8c8e4e@linux-foundation.org> <571DC72F.3030503@suse.cz> Date: Mon, 25 Apr 2016 09:54:51 -0500 Message-ID: Subject: Re: [PATCH v2] z3fold: the 3-fold allocator for compressed pages From: Seth Jennings To: Vlastimil Babka Cc: Andrew Morton , Vitaly Wool , Linux-MM , LKML , Dan Streetman Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2932 Lines: 67 On Mon, Apr 25, 2016 at 2:28 AM, Vlastimil Babka wrote: > 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? (sorry for the dup Vlastimil, didn't reply-to-all) It seems like it could be in the case that most of the pages in your system compress to 1/3 their original size (on average). In my original research, I found that, using lzo, 1/2 a page was more typical. However, if you used deflate, you might be able to push the average down. IMO I do think we should try to merge zbud and z3fold with zbud being the default mode (2 object per page) and have an option to enable the 3 objects per page logic. IIRC that 3rd object logic seemed to be fairly contained. Having the separate would duplicate a lot of very similar code. However, if Andrew is ok with yet another z- allocator, it can just be another zpool backend. I'm fine either way. Just my two cents. Seth >