From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e28smtp04.in.ibm.com (e28smtp04.in.ibm.com [122.248.162.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e28smtp04.in.ibm.com", Issuer "GeoTrust SSL CA" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 70E8B2C011F for ; Wed, 7 Aug 2013 15:13:42 +1000 (EST) Received: from /spool/local by e28smtp04.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 7 Aug 2013 10:36:05 +0530 Received: from d28relay04.in.ibm.com (d28relay04.in.ibm.com [9.184.220.61]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id BAF3B3940058 for ; Wed, 7 Aug 2013 10:43:21 +0530 (IST) Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay04.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r775DOmu38994024 for ; Wed, 7 Aug 2013 10:43:25 +0530 Received: from d28av04.in.ibm.com (localhost [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r775DROe025098 for ; Wed, 7 Aug 2013 10:43:28 +0530 Message-ID: <5201D777.8060303@linux.vnet.ibm.com> Date: Wed, 07 Aug 2013 10:43:27 +0530 From: Aruna Balakrishnaiah MIME-Version: 1.0 To: Tony Luck Subject: Re: [PATCH 00/11] Add compression support to pstore References: <20130715164844.1520.27771.stgit@aruna-ThinkPad-T420> <51FA3B02.7060004@linux.vnet.ibm.com> <3908561D78D1C84285E8C5FCA982C28F31CAA167@ORSMSX106.amr.corp.intel.com> <51FFDC8B.7010909@linux.vnet.ibm.com> <51FFFFEB.3030907@linux.vnet.ibm.com> <5201A9BD.4090503@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: "linuxppc-dev@ozlabs.org" , "paulus@samba.org" , "linux-kernel@vger.kernel.org" , "keescook@chromium.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Tony, On Wednesday 07 August 2013 08:55 AM, Tony Luck wrote: > On Tue, Aug 6, 2013 at 6:58 PM, Aruna Balakrishnaiah > wrote: >> The patch looks right. I will clean it up. Does the issue still persist >> after this? > Things seem to be working - but testing has hardly been extensive (just > a couple of forced panics). > > I do have one other question. In this code: > >>> if (compressed && (type == PSTORE_TYPE_DMESG)) { >>> big_buf_sz = (psinfo->bufsize * 100) / 45; > Where does the magic multiply by 1.45 come from? Is that always enough > for the decompression of "dmesg" type data to succeed? I had this in my cover letter of the series, posting the same from it Writing to persistent store ---------------------------- Compression will reduce the size of oops/panic report to atmost 45% of its original size. (Based on experiments done while providing compression support to nvram by Jim keniston). Hence buffer of size ( (100/45 approx 2.22) * is allocated). The compression parameters selected based on some experiments: compression_level = 6, window_bits = 12, memory_level = 4 which achieved a significant compression of 12 % of uncompressed buffer size tried upto 36k. Data is compressed from the bigger buffer to registered buffer which is returned to backends. Pstore will indicate that with a flag 'compressed' which is passed to backends. Using this flag, backends will add a flag in their header to indicate the data is compressed or not while writing to persistent store. The significant compression that I have mentioned had repeated occurrences in the text. When I tried with plain text I saw compression of around 45% with compression parameters I have used. If the record size is fixed across all the backends then it would be easy to come up with a pre defined set of compression parameters as well as the buffer size of compressed/decompressed data based on experiments. In power as of now, the maximum size of the record is 4k. So compression support on power was provided with multiply (100/45) considering the maximum record size to be 4k. How is it with erst and efivars? - Aruna > -Tony >