Messages in this thread | | | Date | Wed, 07 Aug 2013 10:43:27 +0530 | From | Aruna Balakrishnaiah <> | Subject | Re: [PATCH 00/11] Add compression support to pstore |
| |
Hi Tony,
On Wednesday 07 August 2013 08:55 AM, Tony Luck wrote: > On Tue, Aug 6, 2013 at 6:58 PM, Aruna Balakrishnaiah > <aruna@linux.vnet.ibm.com> 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) *<registered_buffer> 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 >
| |