Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754197AbdHYFgK (ORCPT ); Fri, 25 Aug 2017 01:36:10 -0400 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:55886 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751541AbdHYFgJ (ORCPT ); Fri, 25 Aug 2017 01:36:09 -0400 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.220.163 X-Original-MAILFROM: minchan@kernel.org Date: Fri, 25 Aug 2017 14:36:07 +0900 From: Minchan Kim To: Sergey Senozhatsky Cc: Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org, Nick Terrell Subject: Re: [PATCH] zram: add zstd to the supported algorithms list Message-ID: <20170825053606.GA27787@blaptop> References: <20170824014936.4738-1-sergey.senozhatsky@gmail.com> <20170824043038.GA13922@bgram> <20170824140440.GA5535@tigerII.localdomain> <20170825045036.GA26819@blaptop> <20170825050644.GB5876@jagdpanzerIV.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170825050644.GB5876@jagdpanzerIV.localdomain> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1495 Lines: 35 On Fri, Aug 25, 2017 at 02:06:44PM +0900, Sergey Senozhatsky wrote: < snip > > > Off-topic: > > > > In all ways, zstd beats deflate. Nick, Right? > > > > With zstd, I doubt we should show "deflate" to user. Many options just > > make user confused. > > The inflate have been there for representing high comp ratio but slower > > speed. However, zstd is better unconditionally compared to deflate > > so how about replacing deflate with zstd? > > > > Sergey, what do you think about it? > > hmmm... frankly, I don't think it would confuse anyone. the code is > there - compiled - anyway, and the module is visible in /proc/crypto > etc. if we will make it unavailable in zram then this can be confusing, > probably... if anyone ever pays any attention at all. my guess is that > people look what's in /sys/block/zram0/comp_algorithm just once, then > they set up a create-zram script/systemd unit file/etc. and forget > about it. Although we don't show "deflate", zram still supports it so is it okay for the user forgotten about it? and zram still doesn't show all of compression algorithm in system. If I misunderstood your point, please, clarify. Again, my point is that I want to show limited representative compression (high speed/low comp, low speed/high comp, mid/mid) algorithm via /sys/block/zram0/comp_algorithm rather than adding new entry whenever new algorithm is added on. If others want something else algorithms by some reason, he still can do it. We didn't prevent it.