On Thursday 08 August 2013 09:38 AM, Aruna Balakrishnaiah wrote:
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.l...@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 sum of first two records is less than kmsg_bytes, so it captures the 3rd
record.
Only after 3rd record is captured and written total is evaluated against
kmsg_bytes
when itexceeds the limit it stops capturing the next one.
This shall happen even without compression right? If total is checked before
write this can be avoided.
- Aruna
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
_______________________________________________
Linuxppc-dev mailing list
linuxppc-...@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
