From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752747AbcBVAjc (ORCPT ); Sun, 21 Feb 2016 19:39:32 -0500 Received: from mail-pf0-f181.google.com ([209.85.192.181]:34534 "EHLO mail-pf0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752383AbcBVAja (ORCPT ); Sun, 21 Feb 2016 19:39:30 -0500 Date: Mon, 22 Feb 2016 09:40:47 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Andrew Morton , Joonsoo Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Message-ID: <20160222004047.GA4958@swordfish> References: <1456061274-20059-1-git-send-email-sergey.senozhatsky@gmail.com> <1456061274-20059-3-git-send-email-sergey.senozhatsky@gmail.com> <20160222000436.GA21710@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160222000436.GA21710@bbox> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On (02/22/16 09:04), Minchan Kim wrote: [..] > max_zpage_size was there since zram's grandpa(ie, ramzswap). > AFAIR, at that time, it works to forward incompressible > (e.g, PAGE_SIZE/2) page to backing swap if it presents. > If it doesn't have any backing swap and it's incompressbile > (e.g, PAGE_SIZE*3/4), it stores it as uncompressed page > to avoid *decompress* overhead later. "PAGE_SIZE * 3 / 4" introduces a bigger memory overhead than decompression of 3K bytes later. > And Nitin want to make it as tunable parameter. I agree the > approach because I don't want to make coupling between zram > and allocator as far as possible. > > If huge class is pain they are. > it's allocator problem, not zram stuff. the allocator's problems start at the point where zram begins to have opinion on what should be stored as ->huge object and what should not. it's not up to zram to enforce this. > I think we should try to remove such problem in zsmalloc layer, > firstly. zram asks to store a PAGE_SIZE sized object, what zsmalloc can possible do about this? > Having said that, I agree your claim that uncompressible pages > are pain. I want to handle the problem as multiple-swap apparoach. zram is not just for swapping. as simple as that. and enforcing a multi-swap approach on folks who use zram for swap doesn't look right to me. > For that, we should introduce new knob in zram layer like Nitin > did and make it configurable so we could solve the problem of > single zram-swap system as well as multiple swap system. a 'bad compression' watermark knob? isn't it an absolutely low level thing no one ever should see? -ss