From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751497AbdDBN5B (ORCPT ); Sun, 2 Apr 2017 09:57:01 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:44837 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751356AbdDBN5A (ORCPT ); Sun, 2 Apr 2017 09:57:00 -0400 Date: Sun, 2 Apr 2017 06:56:59 -0700 From: Matthew Wilcox To: Vlastimil Babka Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC] mm/crypto: add tunable compression algorithm for zswap Message-ID: <20170402135659.GA10812@bombadil.infradead.org> References: <20170401211813.15146-1-vbabka@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170401211813.15146-1-vbabka@suse.cz> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 01, 2017 at 11:18:13PM +0200, Vlastimil Babka wrote: > In this prototype patch, it offers three predefined ratios, but nothing > prevents more fine-grained settings, except the current crypto API (or my > limited knowledge of it, but I'm guessing nobody really expected the > compression ratio to be tunable). So by doing > > echo tco50 > /sys/module/zswap/parameters/compressor > > you get 50% compression ratio, guaranteed! This setting and zbud are just the > perfect buddies, if you prefer the nice and simple allocator. Zero internal > fragmentation! [...] > +struct tco_ctx { > + char ratio; > +}; You say this is a ratio, but it's a plain char. Clearly it should be a floating point number; what if I want to achieve 2/3 compression? Or if I'm a disgruntled sysadmin wanting to show how much more Linux suxks than BSD, I might want to expand memory when it goes to swap, perhaps taking up an extra 25%. Maybe we could get away with char numerator; char denominator to allow for the most common rationals, but a floating point ratio would be easier to program with and allow for maximum flexibility. I don't think we need to have as much precision as a double; a plain float should suffice.