From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755826AbcCaGe6 (ORCPT ); Thu, 31 Mar 2016 02:34:58 -0400 Received: from mail-pa0-f51.google.com ([209.85.220.51]:33347 "EHLO mail-pa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755763AbcCaGe5 (ORCPT ); Thu, 31 Mar 2016 02:34:57 -0400 Date: Thu, 31 Mar 2016 15:34:16 +0900 From: Sergey Senozhatsky To: Minchan Kim Cc: Sergey Senozhatsky , Sergey Senozhatsky , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: zram: per-cpu compression streams Message-ID: <20160331063416.GA3343@swordfish> References: <20160323081209.GC512@swordfish> <20160324234149.GB4046@bbox> <20160325014706.GA650@swordfish> <20160328032135.GA31023@bbox> <20160330083419.GA2769@swordfish> <20160330221233.GA6736@bbox> <20160331012626.GB1758@swordfish> <20160331055355.GD6736@bbox> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160331055355.GD6736@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 Hello Minchan, On (03/31/16 14:53), Minchan Kim wrote: > Hello Sergey, > > > that's a good question. I quickly looked into the fio source code, > > we need to use "buffer_pattern=str" option, I think. so the buffers > > will be filled with the same data. > > > > I don't mind to have buffer_compress_percentage as a separate test (set > > as a local test option), but I think that using common buffer pattern > > adds more confidence when we compare test results. > > If we both uses same "buffer_compress_percentage=something", it's > good to compare. The benefit of buffer_compress_percentage is we can > change compression ratio easily in zram testing and see various > test to see what compression ratio or speed affects the system. let's start with "common data" (buffer_pattern=str), not common compression ratio. buffer_compress_percentage=something is calculated for which compression algorithm? deflate (zlib)? or it's something else? we use lzo/lz4, common data is more predictable. [..] > > sure. > > I tested with you suggested parameter. > In my side, win is better compared to my previous test but it seems > your test is so fast. IOW, filesize is small and loops is just 1. > Please test filesize=500m loops=10 or 20. that will require 5G zram, I don't have that much ram on the box so I'll test later today on another box. I split the device size between jobs. if I have 10 jobs, then the file size of each job is DISK_SIZE/10; but in total jobs write/read DEVICE_SZ bytes. jobs start with large 1 * DEVICE_SZ/1 files and go down to 10 * DEVICE_SZ/10 files. > It can make your test more stable and enhance is 10~20% in my side. > Let's discuss further once test result between us is consistent. -ss