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 S1751684AbdF1Pnf (ORCPT <rfc822;w@1wt.eu>);
        Wed, 28 Jun 2017 11:43:35 -0400
Received: from mail-pf0-f176.google.com ([209.85.192.176]:34210 "EHLO
        mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751515AbdF1Pna (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 28 Jun 2017 11:43:30 -0400
Date: Thu, 29 Jun 2017 00:41:57 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        linux-kernel@vger.kernel.org, Juneho Choi <juno.choi@lge.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        kernel-team <kernel-team@lge.com>
Subject: Re: [PATCH v1 0/7] writeback incompressible pages to storage
Message-ID: <20170628154157.GA528@tigerII.localdomain>
References: <1498459987-24562-1-git-send-email-minchan@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1498459987-24562-1-git-send-email-minchan@kernel.org>
User-Agent: Mutt/1.8.3 (2017-05-23)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello,

On (06/26/17 15:52), Minchan Kim wrote:
[..]
> zRam is useful for memory saving with compressible pages but sometime,
> workload can be changed and system has lots of incompressible pages
> which is very harmful for zram.

could do. that makes zram quite complicated, to be honest. no offense,
but the whole zram's "good compression" margin looks to me completely
random and quite unreasonable. building a complex logic atop of random
logic is a bit tricky. but I see what problem you are trying to address.

> This patch supports writeback feature of zram so admin can set up
> a block device and with it, zram can save the memory via writing
> out the incompressile pages once it found it's incompressible pages
> (1/4 comp ratio) instead of keeping the page in memory.

hm, alternative idea. just an idea. can we try compressing the page
with another algorithm? example: downcast from lz4 to zlib? we can
set up a fallback "worst case" algorithm, so each entry can contain
additional flag that would tell if the src page was compressed with
the fast or slow algorithm. that sounds to me easier than "create a
new block device and bond it to zram, etc". but I may be wrong.

	-ss