From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1426061AbcBRKR4 (ORCPT <rfc822;w@1wt.eu>);
	Thu, 18 Feb 2016 05:17:56 -0500
Received: from mail-pf0-f170.google.com ([209.85.192.170]:33645 "EHLO
	mail-pf0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1425207AbcBRKRx (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 18 Feb 2016 05:17:53 -0500
Date: Thu, 18 Feb 2016 19:19:09 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Joonsoo Kim <js1304@gmail.com>, Andrew Morton <akpm@linux-foundation.org>,
        Minchan Kim <minchan@kernel.org>,
        Linux Memory Management List <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [RFC PATCH 3/3] mm/zsmalloc: change ZS_MAX_PAGES_PER_ZSPAGE
Message-ID: <20160218101909.GB503@swordfish>
References: <1455764556-13979-1-git-send-email-sergey.senozhatsky@gmail.com>
 <1455764556-13979-4-git-send-email-sergey.senozhatsky@gmail.com>
 <CAAmzW4O-yQ5GBTE-6WvCL-hZeqyW=k3Fzn4_9G2qkMmp=ceuJg@mail.gmail.com>
 <20160218095536.GA503@swordfish>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160218095536.GA503@swordfish>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On (02/18/16 18:55), Sergey Senozhatsky wrote:
> > There is a reason that it is order of 2. Increasing ZS_MAX_PAGES_PER_ZSPAGE
> > is related to ZS_MIN_ALLOC_SIZE. If we don't have enough OBJ_INDEX_BITS,
> > ZS_MIN_ALLOC_SIZE would be increase and it causes regression on some
> > system.
> 
> Thanks!
> 
> do you mean PHYSMEM_BITS != BITS_PER_LONG systems? PAE/LPAE? isn't it
> the case that on those systems ZS_MIN_ALLOC_SIZE already bigger than 32?

I mean, yes, there are ZS_ALIGN requirements that I completely ignored,
thanks for pointing that out.

just saying, not insisting on anything, theoretically, trading 32 bit size
objects in exchange of reducing a much bigger memory wastage is sort of
interesting. zram stores objects bigger than 3072 as huge objects, leaving
4096-3072 bytes unused, and it'll take 4096-3072/32 = 4000  32 bit objects
to beat that single 'bad' compression object in storing inefficiency...

well, patches 0001/0002 are trying to address this a bit, but the biggest
problem is still there: we have too many ->huge classes and they are a bit
far from good.

	-ss