From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) by kanga.kvack.org (Postfix) with ESMTP id 0E4386B0005 for ; Thu, 14 Apr 2016 04:48:55 -0400 (EDT) Received: by mail-lf0-f69.google.com with SMTP id l15so41143662lfg.2 for ; Thu, 14 Apr 2016 01:48:54 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id is6si44145784wjb.96.2016.04.14.01.48.53 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 14 Apr 2016 01:48:53 -0700 (PDT) Subject: Re: [PATCH] z3fold: the 3-fold allocator for compressed pages References: <570F4F5F.6070209@gmail.com> From: Vlastimil Babka Message-ID: <570F5973.40809@suse.cz> Date: Thu, 14 Apr 2016 10:48:51 +0200 MIME-Version: 1.0 In-Reply-To: <570F4F5F.6070209@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Vitaly Wool , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Seth Jennings , Andrew Morton , Dan Streetman On 04/14/2016 10:05 AM, 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. So the obvious question is, why a separate allocator and not extend zbud? I didn't study the code, nor notice a design/algorithm overview doc, but it seems z3fold keeps the idea of one compressed page at the beginning, one at the end of page frame, but it adds another one in the middle? Also how is the buddy-matching done? Thanks, Vlastimil -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754611AbcDNIs5 (ORCPT ); Thu, 14 Apr 2016 04:48:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:32972 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754549AbcDNIsy (ORCPT ); Thu, 14 Apr 2016 04:48:54 -0400 Subject: Re: [PATCH] z3fold: the 3-fold allocator for compressed pages To: Vitaly Wool , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <570F4F5F.6070209@gmail.com> Cc: Seth Jennings , Andrew Morton , Dan Streetman From: Vlastimil Babka Message-ID: <570F5973.40809@suse.cz> Date: Thu, 14 Apr 2016 10:48:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <570F4F5F.6070209@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/14/2016 10:05 AM, 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. So the obvious question is, why a separate allocator and not extend zbud? I didn't study the code, nor notice a design/algorithm overview doc, but it seems z3fold keeps the idea of one compressed page at the beginning, one at the end of page frame, but it adds another one in the middle? Also how is the buddy-matching done? Thanks, Vlastimil