From: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
To: Tony Luck <tony.luck@gmail.com>
Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>,
"paulus@samba.org" <paulus@samba.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"keescook@chromium.org" <keescook@chromium.org>
Subject: Re: [PATCH 00/11] Add compression support to pstore
Date: Thu, 08 Aug 2013 09:38:18 +0530 [thread overview]
Message-ID: <520319B2.1080906@linux.vnet.ibm.com> (raw)
In-Reply-To: <CA+8MBbJk63N3+YLUGDmGP5jrVc2mLa0Pn-QrqPk1xatknTVVEQ@mail.gmail.com>
Hi Tony,
On Thursday 08 August 2013 03:52 AM, Tony Luck wrote:
> On Tue, Aug 6, 2013 at 10:35 PM, Tony Luck <tony.luck@gmail.com> wrote:
>> ERST is at the whim of the BIOS writer (the ACPI standard doesn't provide any
>> suggestions on record sizes). My systems support ~6K record size.
> Off by a little - 7896 bytes on my current machine.
>
>> efivars has, IIRC, a 1k limit coded in the Linux back end.
> My memory was correct for this one.
>
> Adding a little tracing to pstore_getrecords() I see this:
>
> pstore: inflated 3880 bytes compressed to 17459 bytes
> pstore: inflated 2567 bytes compressed to 17531 bytes
> pstore: inflated 4018 bytes compressed to 17488 bytes
>
> Which isn't at all what I expected. The ERST backend
> advertised a bufsize of 7896, and I have the default
> kmsg_bytes of 10240. So on my forced panic the code
> decided to create a three part pstore dump. The sum of
> the pieces is close to, but a little over the target of 10K.
> But I don't understand why the compressed sizes are so
> much smaller that the ERST backend block size.
The sizes of compressed text depends on the nature of uncompressed
data that is captured from kmsg_dump, considering the worst
case of plain text based on experiments 45% was thecompression achieved.
So we chose a buffer of size psinfo->bufsize * 100/45.
If the uncompressed data captured was more of plain text nature then it
would take up size close to ERST backend block size. Thats the reason
you see compressed data of 2.5k to 4.0k. 2.5k would have more
repeated occurrences than 4.0k.
The sum of 3 pstore records should not have exceeded kmsg_bytes.
Is it after adding total_len in the fix patch? Will take a look at it.
> The uncompressed sizes appear to be close to constant.
> The compression ratios vary from 14% to 23%
>
> Why do we get three small parts instead of two bigger
> ones close the the 7896 ERST bufsize?
Same explanation as given above.
>
> -Tony
>
next prev parent reply other threads:[~2013-08-08 4:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-15 16:55 [PATCH 00/11] Add compression support to pstore Aruna Balakrishnaiah
2013-07-15 16:55 ` [PATCH 01/11] powerpc/pseries: Remove (de)compression in nvram with pstore enabled Aruna Balakrishnaiah
2013-07-15 16:55 ` [PATCH 02/11] pstore: Add new argument 'compressed' in pstore write callback Aruna Balakrishnaiah
2013-07-15 16:55 ` [PATCH 03/11] pstore/Kconfig: Select ZLIB_DEFLATE and ZLIB_INFLATE when PSTORE is selected Aruna Balakrishnaiah
2013-07-15 16:55 ` [PATCH 04/11] pstore: Add compression support to pstore Aruna Balakrishnaiah
2013-07-15 16:55 ` [PATCH 05/11] pstore: Introduce new argument 'compressed' in the read callback Aruna Balakrishnaiah
2013-07-15 16:56 ` [PATCH 06/11] pstore: Provide decompression support to pstore Aruna Balakrishnaiah
2013-07-15 16:56 ` [PATCH 07/11] pstore: Add file extension to pstore file if compressed Aruna Balakrishnaiah
2013-07-15 16:56 ` [PATCH 08/11] powerpc/pseries: Read and write to the 'compressed' flag of pstore Aruna Balakrishnaiah
2013-07-15 16:56 ` [PATCH 09/11] erst: " Aruna Balakrishnaiah
2013-07-15 16:56 ` [PATCH 10/11] efi-pstore: " Aruna Balakrishnaiah
2013-07-15 16:57 ` [PATCH 11/11] pstore/ram: " Aruna Balakrishnaiah
2013-08-01 10:40 ` [PATCH 00/11] Add compression support to pstore Aruna Balakrishnaiah
2013-08-01 23:42 ` Luck, Tony
2013-08-02 21:39 ` Tony Luck
2013-08-02 22:12 ` Tony Luck
2013-08-05 16:41 ` Tony Luck
2013-08-05 17:10 ` Aruna Balakrishnaiah
2013-08-05 18:22 ` Tony Luck
2013-08-05 19:41 ` Aruna Balakrishnaiah
2013-08-05 21:20 ` Tony Luck
2013-08-06 23:36 ` Tony Luck
2013-08-07 1:58 ` Aruna Balakrishnaiah
2013-08-07 3:25 ` Tony Luck
2013-08-07 5:13 ` Aruna Balakrishnaiah
2013-08-07 5:35 ` Tony Luck
2013-08-07 17:30 ` Tony Luck
2013-08-08 4:29 ` Aruna Balakrishnaiah
2013-08-08 5:05 ` Tony Luck
2013-08-07 22:22 ` Tony Luck
2013-08-08 4:08 ` Aruna Balakrishnaiah [this message]
2013-08-09 10:13 ` Aruna Balakrishnaiah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520319B2.1080906@linux.vnet.ibm.com \
--to=aruna@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=tony.luck@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox