7:33 p.m.
The following series implements LZO compression support to
makedumpfile. LZO is as good as in size but by far better in speed
than ZLIB, readucing down time during generation of crash dump and
refiltering.
The RFC discussion was made here:
http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
How to build:
1. Get lzo libraries: lzo, lzo-devel and lzo-minilzo from either of
the following:
1) Original author's website:
http://www.oberhumer.com/opensource/lzo/
2) yum framework on fedora. Older releases don't have the packages.
2. Apply the patch set to makedumpfile v1.4.2.
3. Do make as follows:
$ make USELZO=on
Note: In default, no LZO compression support is included.
How to use:
Introduce new -l option. If a user specify this, makedumpfile
generates dumpfile compressed by pages with lzo compression.
Example)
$ makedumpfile -l vmcore dumpfile
Performance evaluation:
- Kumagai-san's evaluation simulating working servers:
http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
- My evaluation focusing on the worst cases:
http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
LZO Support for crash:
I'll post LZO support patch for crash after makedumpfile merges
these patches.
Changelog:
v1 => v2:
- Add build condition for LZO support. Enable LZO support if
specifying USELZO=on to make command.
- Avoid LONG_MAX/ULONG_MAX redefinitions.
---
HATAYAMA Daisuke (4):
Add build condition for LZO support
Add help and manual messages about LZO compression support
Avoid LONG_MAX/ULONG_MAX redefinitions
Add LZO Support
Makefile | 5 ++++
common.h | 4 +++
diskdump_mod.h | 3 ++-
makedumpfile.8 | 6 +++--
makedumpfile.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++------
makedumpfile.h | 4 +++
print_info.c | 16 +++++++------
7 files changed, 86 insertions(+), 19 deletions(-)
--
HATAYAMA Daisuke
7:33 p.m.
New subject: [PATCH makedumpfile v2 1/4] Add LZO Support
Add -l option as one of the command-line options users can specify. If
-l option is specified, then makedumpfile generates dumpfile in
kdump-compressed format with lzo compression by each page.
Signed-off-by: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com>
---
diskdump_mod.h | 3 ++-
makedumpfile.c | 57 +++++++++++++++++++++++++++++++++++++++++++++++---------
makedumpfile.h | 2 ++
3 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/diskdump_mod.h b/diskdump_mod.h
index c1de972..e672485 100644
--- a/diskdump_mod.h
+++ b/diskdump_mod.h
@@ -78,7 +78,8 @@ struct kdump_sub_header {
};
/* page flags */
-#define DUMP_DH_COMPRESSED 0x1 /* page is compressed */
+#define DUMP_DH_COMPRESSED_ZLIB 0x1 /* page is compressed with zlib */
+#define DUMP_DH_COMPRESSED_LZO 0x2 /* paged is compressed with lzo */
/* descriptor of each page for vmcore */
typedef struct page_desc {
diff --git a/makedumpfile.c b/makedumpfile.c
index c51fda3..e0079b8 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -257,7 +257,7 @@ readpmem_kdump_compressed(unsigned long long paddr, void *bufptr,
size_t size)
goto error;
}
- if (pd.flags & DUMP_DH_COMPRESSED) {
+ if (pd.flags & DUMP_DH_COMPRESSED_ZLIB) {
retlen = info->page_size;
ret = uncompress((unsigned char *)buf2, &retlen,
(unsigned char *)buf, pd.size);
@@ -266,6 +266,17 @@ readpmem_kdump_compressed(unsigned long long paddr, void *bufptr,
size_t size)
goto error;
}
memcpy(bufptr, buf2 + page_offset, size);
+ } else if (info->flag_lzo_support
+ && (pd.flags & DUMP_DH_COMPRESSED_LZO)) {
+ retlen = info->page_size;
+ ret = lzo1x_decompress_safe((unsigned char *)buf, pd.size,
+ (unsigned char *)buf2, &retlen,
+ LZO1X_MEM_DECOMPRESS);
+ if ((ret != LZO_E_OK) || (retlen != info->page_size)) {
+ ERRMSG("Uncompress failed: %d\n", ret);
+ goto error;
+ }
+ memcpy(bufptr, buf2 + page_offset, size);
} else
memcpy(bufptr, buf + page_offset, size);
@@ -2498,6 +2509,9 @@ initial(void)
unsigned long size;
int debug_info = FALSE;
+ if (lzo_init() == LZO_E_OK)
+ info->flag_lzo_support = TRUE;
+
if (!is_xen_memory() && info->flag_exclude_xen_dom) {
MSG("'-X' option is disable,");
MSG("because %s is not Xen's memory core image.\n",
info->name_memory);
@@ -4665,10 +4679,11 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data
*cd_page)
off_t offset_data = 0;
struct disk_dump_header *dh = info->dump_header;
unsigned char buf[info->page_size], *buf_out = NULL;
- unsigned long len_buf_out;
+ unsigned long len_buf_out, len_buf_out_zlib, len_buf_out_lzo;
struct dump_bitmap bitmap2;
struct timeval tv_start;
const off_t failed = (off_t)-1;
+ lzo_bytep wrkmem = NULL;
int ret = FALSE;
@@ -4677,7 +4692,16 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data
*cd_page)
initialize_2nd_bitmap(&bitmap2);
- len_buf_out = compressBound(info->page_size);
+ if ((wrkmem = malloc(LZO1X_1_MEM_COMPRESS)) == NULL) {
+ ERRMSG("Can't allocate memory for the working memory. %s\n",
+ strerror(errno));
+ goto out;
+ }
+
+ len_buf_out_zlib = compressBound(info->page_size);
+ len_buf_out_lzo = info->page_size + info->page_size / 16 + 64 + 3;
+ len_buf_out = MAX(len_buf_out_zlib, len_buf_out_lzo);
+
if ((buf_out = malloc(len_buf_out)) == NULL) {
ERRMSG("Can't allocate memory for the compression buffer. %s\n",
strerror(errno));
@@ -4759,11 +4783,21 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data
*cd_page)
* Compress the page data.
*/
size_out = len_buf_out;
- if (info->flag_compress
- && (compress2(buf_out, &size_out, buf,
- info->page_size, Z_BEST_SPEED) == Z_OK)
+ if ((info->flag_compress & DUMP_DH_COMPRESSED_ZLIB)
+ && ((size_out = len_buf_out),
+ compress2(buf_out, &size_out, buf, info->page_size,
+ Z_BEST_SPEED) == Z_OK)
&& (size_out < info->page_size)) {
- pd.flags = 1;
+ pd.flags = DUMP_DH_COMPRESSED_ZLIB;
+ pd.size = size_out;
+ memcpy(buf, buf_out, pd.size);
+ } else if (info->flag_lzo_support
+ && (info->flag_compress & DUMP_DH_COMPRESSED_LZO)
+ && ((size_out = info->page_size),
+ lzo1x_1_compress(buf, info->page_size, buf_out,
+ &size_out, wrkmem) == LZO_E_OK)
+ && (size_out < info->page_size)) {
+ pd.flags = DUMP_DH_COMPRESSED_LZO;
pd.size = size_out;
memcpy(buf, buf_out, pd.size);
} else {
@@ -4806,6 +4840,8 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data
*cd_page)
out:
if (buf_out != NULL)
free(buf_out);
+ if (wrkmem != NULL)
+ free(wrkmem);
return ret;
}
@@ -6896,7 +6932,7 @@ main(int argc, char *argv[])
info->block_order = DEFAULT_ORDER;
message_level = DEFAULT_MSG_LEVEL;
- while ((opt = getopt_long(argc, argv, "b:cDd:EFfg:hi:MRrsvXx:", longopts,
+ while ((opt = getopt_long(argc, argv, "b:cDd:EFfg:hi:lMRrsvXx:", longopts,
NULL)) != -1) {
switch (opt) {
case 'b':
@@ -6906,7 +6942,7 @@ main(int argc, char *argv[])
info->name_filterconfig = optarg;
break;
case 'c':
- info->flag_compress = 1;
+ info->flag_compress = DUMP_DH_COMPRESSED_ZLIB;
break;
case 'D':
flag_debug = TRUE;
@@ -6945,6 +6981,9 @@ main(int argc, char *argv[])
goto out;
info->flag_sadump_diskset = 1;
break;
+ case 'l':
+ info->flag_compress = DUMP_DH_COMPRESSED_LZO;
+ break;
case 'm':
message_level = atoi(optarg);
break;
diff --git a/makedumpfile.h b/makedumpfile.h
index ebb8929..9594ca7 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -31,6 +31,7 @@
#include <libelf.h>
#include <byteswap.h>
#include <getopt.h>
+#include <lzo/lzo1x.h>
#include "common.h"
#include "dwarf_info.h"
#include "diskdump_mod.h"
@@ -767,6 +768,7 @@ struct DumpInfo {
int num_dump_level; /* number of dump level */
int array_dump_level[NUM_ARRAY_DUMP_LEVEL];
int flag_compress; /* flag of compression */
+ int flag_lzo_support; /* flag of LZO compression support */
int flag_elf_dumpfile; /* flag of creating ELF dumpfile */
int flag_generate_vmcoreinfo;/* flag of generating vmcoreinfo file */
int flag_read_vmcoreinfo; /* flag of reading vmcoreinfo file */
7:34 p.m.
New subject: [PATCH makedumpfile v2 2/4] Avoid LONG_MAX/ULONG_MAX redefinitions
common.h locally defines LONG_MAX and ULONG_MAX. But when importing
lzo library's headers, ulimit.h that is imported implicitly is also
imported so the two definitions collide, and the warning message below
is displayed.
gcc -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-DVERSION='"1.4.2"' -DRELEASE_DATE='"25 January 2012"'
-D__x86_64__ -DUSELZO print_info.o dwarf_info.o elf_info.o erase_info.o sadump_info.o
arch/arm.o arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o arch/s390x.o -o makedumpfile
makedumpfile.c -llzo2 -ldw -lbz2 -lebl -ldl -lelf -lz
In file included from makedumpfile.h:37:0,
from makedumpfile.c:16:
common.h:23:0: warning: "LONG_MAX" redefined
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/include/limits.h:132:0: note: this is the location
of the previous definition
common.h:24:0: warning: "ULONG_MAX" redefined
/usr/lib/gcc/x86_64-redhat-linux/4.5.1/include/limits.h:136:0: note: this is the location
of the previous definition
To avoid this problem, check if each has already defiend before
defining it.
Signed-off-by: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com>
---
common.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/common.h b/common.h
index a4cc2f7..6ad3ca7 100644
--- a/common.h
+++ b/common.h
@@ -20,8 +20,12 @@
#define FALSE (0)
#define ERROR (-1)
+#ifndef LONG_MAX
#define LONG_MAX ((long)(~0UL>>1))
+#endif
+#ifndef ULONG_MAX
#define ULONG_MAX (~0UL)
+#endif
#define ULONGLONG_MAX (~0ULL)
#define MAX(a,b) ((a) > (b) ? (a) : (b))
7:34 p.m.
New subject: [PATCH makedumpfile v2 3/4] Add help and manual messages about LZO compression support
Signed-off-by: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com>
---
makedumpfile.8 | 6 +++---
print_info.c | 16 ++++++++--------
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/makedumpfile.8 b/makedumpfile.8
index 4733420..f607bf5 100644
--- a/makedumpfile.8
+++ b/makedumpfile.8
@@ -121,8 +121,8 @@ configuration, you need to use --diskset option.
.SH OPTIONS
.TP
-\fB\-c\fR
-Compress dump data by each page.
+\fB\-c,\-l\fR
+Compress dump data by each page using zlib for -c option or lzo for -l option.
.br
A user cannot specify this option with \-E option, because the ELF format does
not support compressed data.
@@ -196,7 +196,7 @@ by dump_level 11, makedumpfile retries it by dump_level 31.
\fB\-E\fR
Create \fIDUMPFILE\fR in the ELF format.
.br
-This option cannot be specified with \-c option, because the ELF format does not
+This option cannot be specified with either of \-c option or \-l option, because the ELF
format does not
support compressed data.
.br
.B Example:
diff --git a/print_info.c b/print_info.c
index 31460b7..237892e 100644
--- a/print_info.c
+++ b/print_info.c
@@ -35,15 +35,15 @@ print_usage(void)
MSG("\n");
MSG("Usage:\n");
MSG(" Creating DUMPFILE:\n");
- MSG(" # makedumpfile [-c|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE
DUMPFILE\n");
+ MSG(" # makedumpfile [-c|-l|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO] VMCORE
DUMPFILE\n");
MSG("\n");
MSG(" Creating DUMPFILE with filtered kernel data specified through filter
config\n");
MSG(" file:\n");
- MSG(" # makedumpfile [-c|-E] [-d DL] -x VMLINUX --config FILTERCONFIGFILE
VMCORE\n");
+ MSG(" # makedumpfile [-c|-l|-E] [-d DL] -x VMLINUX --config FILTERCONFIGFILE
VMCORE\n");
MSG(" DUMPFILE\n");
MSG("\n");
MSG(" Outputting the dump data in the flattened format to the standard
output:\n");
- MSG(" # makedumpfile -F [-c|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO]
VMCORE\n");
+ MSG(" # makedumpfile -F [-c|-l|-E] [-d DL] [-x VMLINUX|-i VMCOREINFO]
VMCORE\n");
MSG("\n");
MSG(" Rearranging the dump data in the flattened format to a readable
DUMPFILE:\n");
MSG(" # makedumpfile -R DUMPFILE\n");
@@ -70,14 +70,14 @@ print_usage(void)
MSG("\n");
MSG("\n");
MSG(" Creating DUMPFILE from multiple VMCOREs generated on sadump diskset
configuration:\n");
- MSG(" # makedumpfile [-c] [-d DL] -x VMLINUX --diskset=VMCORE1
--diskset=VMCORE2\n");
+ MSG(" # makedumpfile [-c|-l] [-d DL] -x VMLINUX --diskset=VMCORE1
--diskset=VMCORE2\n");
MSG(" [--diskset=VMCORE3 ..] DUMPFILE\n");
MSG("\n");
MSG("\n");
MSG("Available options:\n");
- MSG(" [-c]:\n");
- MSG(" Compress dump data by each page.\n");
- MSG(" A user cannot specify this option with -E option, because the ELF
format\n");
+ MSG(" [-c|-l]:\n");
+ MSG(" Compress dump data by each page using zlib for -c option and lzo for -l
option.\n");
+ MSG(" A user cannot specify either of these options with -E option, because
the ELF format\n");
MSG(" does not support compressed data.\n");
MSG(" THIS IS ONLY FOR THE CRASH UTILITY.\n");
MSG("\n");
@@ -103,7 +103,7 @@ print_usage(void)
MSG("\n");
MSG(" [-E]:\n");
MSG(" Create DUMPFILE in the ELF format.\n");
- MSG(" This option cannot be specified with -c option, because the
ELF\n");
+ MSG(" This option cannot be specified with either of -c option or -l option,
because the ELF\n");
MSG(" format does not support compressed data.\n");
MSG("\n");
MSG(" [-x VMLINUX]:\n");
7:34 p.m.
New subject: [PATCH makedumpfile v2 4/4] Add build condition for LZO support
To enable lzo compression support, build makedumpfile as:
$ make USELZO
To disable, as:
$ make
In default, lzo compression support is disabled.
Signed-off-by: HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com>
---
Makefile | 5 +++++
makedumpfile.c | 18 ++++++++++++++++--
makedumpfile.h | 2 ++
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index e6b7b89..55082f7 100644
--- a/Makefile
+++ b/Makefile
@@ -34,6 +34,11 @@ ifneq ($(LINKTYPE), dynamic)
LIBS := -static $(LIBS)
endif
+ifeq ($(USELZO), on)
+LIBS := -llzo2 $(LIBS)
+CFLAGS += -DUSELZO
+endif
+
all: makedumpfile
$(OBJ_PART): $(SRC_PART)
diff --git a/makedumpfile.c b/makedumpfile.c
index e0079b8..717519a 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -266,6 +266,7 @@ readpmem_kdump_compressed(unsigned long long paddr, void *bufptr,
size_t size)
goto error;
}
memcpy(bufptr, buf2 + page_offset, size);
+#ifdef USELZO
} else if (info->flag_lzo_support
&& (pd.flags & DUMP_DH_COMPRESSED_LZO)) {
retlen = info->page_size;
@@ -277,6 +278,7 @@ readpmem_kdump_compressed(unsigned long long paddr, void *bufptr,
size_t size)
goto error;
}
memcpy(bufptr, buf2 + page_offset, size);
+#endif
} else
memcpy(bufptr, buf + page_offset, size);
@@ -2509,8 +2511,10 @@ initial(void)
unsigned long size;
int debug_info = FALSE;
+#ifdef USELZO
if (lzo_init() == LZO_E_OK)
info->flag_lzo_support = TRUE;
+#endif
if (!is_xen_memory() && info->flag_exclude_xen_dom) {
MSG("'-X' option is disable,");
@@ -4679,11 +4683,10 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data
*cd_page)
off_t offset_data = 0;
struct disk_dump_header *dh = info->dump_header;
unsigned char buf[info->page_size], *buf_out = NULL;
- unsigned long len_buf_out, len_buf_out_zlib, len_buf_out_lzo;
+ unsigned long len_buf_out;
struct dump_bitmap bitmap2;
struct timeval tv_start;
const off_t failed = (off_t)-1;
- lzo_bytep wrkmem = NULL;
int ret = FALSE;
@@ -4692,6 +4695,10 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data
*cd_page)
initialize_2nd_bitmap(&bitmap2);
+#ifdef USELZO
+ unsigned long len_buf_out_zlib, len_buf_out_lzo;
+ lzo_bytep wrkmem;
+
if ((wrkmem = malloc(LZO1X_1_MEM_COMPRESS)) == NULL) {
ERRMSG("Can't allocate memory for the working memory. %s\n",
strerror(errno));
@@ -4701,6 +4708,9 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data
*cd_page)
len_buf_out_zlib = compressBound(info->page_size);
len_buf_out_lzo = info->page_size + info->page_size / 16 + 64 + 3;
len_buf_out = MAX(len_buf_out_zlib, len_buf_out_lzo);
+#else
+ len_buf_out = compressBound(info->page_size);
+#endif
if ((buf_out = malloc(len_buf_out)) == NULL) {
ERRMSG("Can't allocate memory for the compression buffer. %s\n",
@@ -4791,6 +4801,7 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data
*cd_page)
pd.flags = DUMP_DH_COMPRESSED_ZLIB;
pd.size = size_out;
memcpy(buf, buf_out, pd.size);
+#ifdef USELZO
} else if (info->flag_lzo_support
&& (info->flag_compress & DUMP_DH_COMPRESSED_LZO)
&& ((size_out = info->page_size),
@@ -4800,6 +4811,7 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data
*cd_page)
pd.flags = DUMP_DH_COMPRESSED_LZO;
pd.size = size_out;
memcpy(buf, buf_out, pd.size);
+#endif
} else {
pd.flags = 0;
pd.size = info->page_size;
@@ -4840,8 +4852,10 @@ write_kdump_pages(struct cache_data *cd_header, struct cache_data
*cd_page)
out:
if (buf_out != NULL)
free(buf_out);
+#ifdef USELZO
if (wrkmem != NULL)
free(wrkmem);
+#endif
return ret;
}
diff --git a/makedumpfile.h b/makedumpfile.h
index 9594ca7..170ac82 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -31,7 +31,9 @@
#include <libelf.h>
#include <byteswap.h>
#include <getopt.h>
+#ifdef USELZO
#include <lzo/lzo1x.h>
+#endif
#include "common.h"
#include "dwarf_info.h"
#include "diskdump_mod.h"
2:16 a.m.
Hello Hatayama-san,
On Thu, 23 Feb 2012 10:33:54 +0900
HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
The following series implements LZO compression support to
makedumpfile. LZO is as good as in size but by far better in speed
than ZLIB, readucing down time during generation of crash dump and
refiltering.
The RFC discussion was made here:
http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
How to build:
1. Get lzo libraries: lzo, lzo-devel and lzo-minilzo from either of
the following:
1) Original author's website:
http://www.oberhumer.com/opensource/lzo/
2) yum framework on fedora. Older releases don't have the packages.
2. Apply the patch set to makedumpfile v1.4.2.
3. Do make as follows:
$ make USELZO=on
Note: In default, no LZO compression support is included.
How to use:
Introduce new -l option. If a user specify this, makedumpfile
generates dumpfile compressed by pages with lzo compression.
Example)
$ makedumpfile -l vmcore dumpfile
Performance evaluation:
- Kumagai-san's evaluation simulating working servers:
http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
- My evaluation focusing on the worst cases:
http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
LZO Support for crash:
I'll post LZO support patch for crash after makedumpfile merges
these patches.
Changelog:
v1 => v2:
- Add build condition for LZO support. Enable LZO support if
specifying USELZO=on to make command.
- Avoid LONG_MAX/ULONG_MAX redefinitions.
Thank you for your work.
I will review your patches for v1.4.4.
Thanks
Atsushi Kumagai
7:38 p.m.
Helllo Kumagai-san,
From: Atsushi Kumagai <kumagai-atsushi(a)mxc.nes.nec.co.jp>
Subject: Re: [PATCH makedumpfile v2 0/4] LZO Compression Support
Date: Thu, 23 Feb 2012 17:16:46 +0900
Thank you for your work.
I will review your patches for v1.4.4.
Could you tell me when you plan to release version 1.4.4? Not
necessarily exact date, rough schedule is enough. I need to post the
corresponding patch to the crash utility's side after LZO feature is
merged into makedumpfile.
Thanks.
HATAYAMA, Daisuke
10:40 p.m.
Hello HATAYAMA-san,
On Thu, 10 May 2012 09:38:29 +0900 (JST)
HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
Helllo Kumagai-san,
From: Atsushi Kumagai <kumagai-atsushi(a)mxc.nes.nec.co.jp>
Subject: Re: [PATCH makedumpfile v2 0/4] LZO Compression Support
Date: Thu, 23 Feb 2012 17:16:46 +0900
> Thank you for your work.
> I will review your patches for v1.4.4.
Could you tell me when you plan to release version 1.4.4? Not
necessarily exact date, rough schedule is enough. I need to post the
corresponding patch to the crash utility's side after LZO feature is
merged into makedumpfile.
At first, I planned to merge features below into v1.4.4.
- vmalloc translation support for PPC32 (by Suzuki K. Poulose)
- LZO Compression Support (by HATAYAMA Daisuke)
- sadump: check if given cpu is online in per-cpu related helper functions
(by HATAYAMA Daisuke)
However, the first one is being discussed and the schedule is not clear.
So, I would like to postpone the feature for v1.4.5 and start testing
the other two for v1.4.4.
If I can start testing now, I will release v1.4.4 in this month.
Thanks
Atsushi Kumagai
11:40 p.m.
From: Atsushi Kumagai <kumagai-atsushi(a)mxc.nes.nec.co.jp>
Subject: Re: [PATCH makedumpfile v2 0/4] LZO Compression Support
Date: Thu, 10 May 2012 12:40:27 +0900
At first, I planned to merge features below into v1.4.4.
- vmalloc translation support for PPC32 (by Suzuki K. Poulose)
- LZO Compression Support (by HATAYAMA Daisuke)
- sadump: check if given cpu is online in per-cpu related helper functions
(by HATAYAMA Daisuke)
However, the first one is being discussed and the schedule is not clear.
So, I would like to postpone the feature for v1.4.5 and start testing
the other two for v1.4.4.
If I can start testing now, I will release v1.4.4 in this month.
Thanks. So the release would be before the release of crash utility's
next version. I'll post the patch for crash utility soon.
Thanks.
HATAYAMA, Daisuke
2:33 a.m.
Hello Hatayama-san,
On Thu, 23 Feb 2012 10:33:54 +0900
HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
The following series implements LZO compression support to
makedumpfile. LZO is as good as in size but by far better in speed
than ZLIB, readucing down time during generation of crash dump and
refiltering.
Sorry for late reply.
[PATCH v2 4/4] allows to use -l option even without USELZO but
lzo compression doesn't work without USELZO.
I think that warning messages should be displayed when -l option is
used on makedumpfile built without USELZO.
So I made v3 patches attached to this mail.
([PATCH v2 1/4] and [PATCH v2 2/4] look good and I didn't change them.)
v2 => v3:
- Add warning messages for invalid -l option.
- Show LZO support status with help messages.
- Add description of USELZO in README and man page.
- (and I will do some cleanups.)
What do you think, Hatayama-san ?
Thanks
Atsushi Kumagai
The RFC discussion was made here:
http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
How to build:
1. Get lzo libraries: lzo, lzo-devel and lzo-minilzo from either of
the following:
1) Original author's website:
http://www.oberhumer.com/opensource/lzo/
2) yum framework on fedora. Older releases don't have the packages.
2. Apply the patch set to makedumpfile v1.4.2.
3. Do make as follows:
$ make USELZO=on
Note: In default, no LZO compression support is included.
How to use:
Introduce new -l option. If a user specify this, makedumpfile
generates dumpfile compressed by pages with lzo compression.
Example)
$ makedumpfile -l vmcore dumpfile
Performance evaluation:
- Kumagai-san's evaluation simulating working servers:
http://lists.infradead.org/pipermail/kexec/2011-December/005868.html
- My evaluation focusing on the worst cases:
http://lists.infradead.org/pipermail/kexec/2011-November/005783.html
LZO Support for crash:
I'll post LZO support patch for crash after makedumpfile merges
these patches.
Changelog:
v1 => v2:
- Add build condition for LZO support. Enable LZO support if
specifying USELZO=on to make command.
- Avoid LONG_MAX/ULONG_MAX redefinitions.
---
HATAYAMA Daisuke (4):
Add build condition for LZO support
Add help and manual messages about LZO compression support
Avoid LONG_MAX/ULONG_MAX redefinitions
Add LZO Support
Makefile | 5 ++++
common.h | 4 +++
diskdump_mod.h | 3 ++-
makedumpfile.8 | 6 +++--
makedumpfile.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++------
makedumpfile.h | 4 +++
print_info.c | 16 +++++++------
7 files changed, 86 insertions(+), 19 deletions(-)
--
HATAYAMA Daisuke
_______________________________________________
kexec mailing list
kexec(a)lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
8:14 a.m.
Hello Kumagai-san,
From: Atsushi Kumagai <kumagai-atsushi(a)mxc.nes.nec.co.jp>
Subject: Re: [PATCH makedumpfile v2 0/4] LZO Compression Support
Date: Fri, 23 Mar 2012 16:33:03 +0900
On Thu, 23 Feb 2012 10:33:54 +0900
HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
> The following series implements LZO compression support to
> makedumpfile. LZO is as good as in size but by far better in speed
> than ZLIB, readucing down time during generation of crash dump and
> refiltering.
Sorry for late reply.
[PATCH v2 4/4] allows to use -l option even without USELZO but
lzo compression doesn't work without USELZO.
I think that warning messages should be displayed when -l option is
used on makedumpfile built without USELZO.
So I made v3 patches attached to this mail.
([PATCH v2 1/4] and [PATCH v2 2/4] look good and I didn't change them.)
v2 => v3:
- Add warning messages for invalid -l option.
- Show LZO support status with help messages.
- Add description of USELZO in README and man page.
- (and I will do some cleanups.)
What do you think, Hatayama-san ?
Thanks. I think the warning message very helpful for users.
BTW, I have a question about future build option of LZO library. You
said previously you're going to introduce autotools. Then, do you
consider default enable if LZO library is present on the environment?
Thanks.
HATAYAMA, Daisuke
12:18 a.m.
Hello Hatayama-san,
On Fri, 23 Mar 2012 17:26:08 +0900 ( )
HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
BTW, I have a question about future build option of LZO library. You
said previously you're going to introduce autotools. Then, do you
consider default enable if LZO library is present on the environment?
I'm afraid I decide not to introduce autotools for the following reasons.
First, because autotools cannot know whether LZO library is prepared in
2nd kernel environment, it cannot decide whether it should link LZO library
dynamically even if LINKTYPE=dynamic is specified.
Second, if autotools behaves differently depending on LINKTYPE, it is difficult
for users to understand.
So, I think that current method is simpler and better than autotools.
Thanks
Atsushi Kumagai
8:14 a.m.
Hello Kumagai-san,
From: Atsushi Kumagai <kumagai-atsushi(a)mxc.nes.nec.co.jp>
Subject: Re: [PATCH makedumpfile v2 0/4] LZO Compression Support
Date: Wed, 28 Mar 2012 14:18:09 +0900
Hello Hatayama-san,
On Fri, 23 Mar 2012 17:26:08 +0900 ( )
HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
> BTW, I have a question about future build option of LZO library. You
> said previously you're going to introduce autotools. Then, do you
> consider default enable if LZO library is present on the environment?
I'm afraid I decide not to introduce autotools for the following reasons.
It's OK if you don't have plan to use autotools.
First, because autotools cannot know whether LZO library is prepared
in
2nd kernel environment, it cannot decide whether it should link LZO library
dynamically even if LINKTYPE=dynamic is specified.
Yes, I of course agree with the fact that makedumpfile for kdump 2nd
kernel should always be built in statically linked way.
But I think two problems are different, that is, the problem making
users easily able to choose build option by autotools, and the problem
guranteeing that the makedumpfile for kdump 2nd kernel be built always
statically.
Second, if autotools behaves differently depending on LINKTYPE, it is
difficult
for users to understand.
If autotools were introduced, then I think we would no longer use
LINKTYPE and we would choose building option through autotools
features. For example, through new options in configure script such as
--enable-lzo-{static,dynamic} for example?
So, I think that current method is simpler and better than autotools.
I agree. I think simpler one is better if it's enough for the purpose.
Thanks.
HATAYAMA, Daisuke
2:59 a.m.
Hello,
Le 28/03/2012 09:50, HATAYAMA Daisuke a écrit :
Yes, I of course agree with the fact that makedumpfile for kdump 2nd
kernel should always be built in statically linked way.
But I think two problems are different, that is, the problem making
users easily able to choose build option by autotools, and the problem
guranteeing that the makedumpfile for kdump 2nd kernel be built always
statically.
I don't see why it should be statically linked. Debian & Ubuntu both use
a dynamically linked makedumpfile for the 2nd kdump kernel.
Debian executes makedumpfile on the 'real' root FS while Ubuntu runs it
in the initramfs. It is simply a chroot on the root FS being mounted on
/root.
HTH,
...Louis
--
Louis Bouchard
Backline Support Analyst
Canonical Ltd
Ubuntu support: http://landscape.canonical.com
8:14 a.m.
Hello,
From: Bouchard Louis <louis.bouchard(a)canonical.com>
Subject: Re: [PATCH makedumpfile v2 0/4] LZO Compression Support
Date: Wed, 28 Mar 2012 09:59:04 +0200
Hello,
Le 28/03/2012 09:50, HATAYAMA Daisuke a écrit :
>
> Yes, I of course agree with the fact that makedumpfile for kdump 2nd
> kernel should always be built in statically linked way.
>
> But I think two problems are different, that is, the problem making
> users easily able to choose build option by autotools, and the problem
> guranteeing that the makedumpfile for kdump 2nd kernel be built always
> statically.
>
I don't see why it should be statically linked. Debian & Ubuntu both use
a dynamically linked makedumpfile for the 2nd kdump kernel.
Debian executes makedumpfile on the 'real' root FS while Ubuntu runs it
in the initramfs. It is simply a chroot on the root FS being mounted on
/root.
Thanks. I've noticed the fact on Debian for the first time.
Root filesystem can be broken due to filesystem related bugs or disk
crash. So, on fedora/RHEL environments, root filesystem is not mounted
in kdump initrd/initramfs. Necessary resources in 2nd kernel,
including makedumpfile, are all packed in kdump initrd/initramfs.
Thanks.
HATAYAMA, Daisuke
4433
days inactive
4510
days old
devel@lists.crash-utility.osci.io
14 comments
3 participants
participants (3)
-
Atsushi Kumagai -
Bouchard Louis -
HATAYAMA Daisuke