Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic
@ 2014-07-11  7:15 Baoquan He
  2014-07-11  7:15 ` [PATCH 2/7] functions to get crashkernel memory range Baoquan He
                   ` (6 more replies)
  0 siblings, 7 replies; 22+ messages in thread
From: Baoquan He @ 2014-07-11  7:15 UTC (permalink / raw)
  To: kexec, kumagai-atsushi; +Cc: Baoquan He, vgoyal

This is a code bug. In initialize_2nd_bitmap_cyclic pfn_memhole is
calculated, however it's not initialized before that. If an available
pfn_memhole is wanted after get_num_dumpable_cyclic invocation,
initializing pfn_memhole in get_num_dumpable_cyclic is necessary.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 makedumpfile.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/makedumpfile.c b/makedumpfile.c
index 3884aa5..760bfd1 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -5588,6 +5588,8 @@ get_num_dumpable_cyclic(void)
 	mdf_pfn_t pfn, num_dumpable=0;
 	struct cycle cycle = {0};
 
+	pfn_memhole = info->max_mapnr;
+
 	for_each_cycle(0, info->max_mapnr, &cycle)
 	{
 		if (!exclude_unnecessary_pages_cyclic(&cycle))
-- 
1.8.4.2


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 2/7] functions to get crashkernel memory range
  2014-07-11  7:15 [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
@ 2014-07-11  7:15 ` Baoquan He
  2014-07-11  7:16 ` [PATCH 3/7] preparation functions for parsing vmcoreinfo Baoquan He
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 22+ messages in thread
From: Baoquan He @ 2014-07-11  7:15 UTC (permalink / raw)
  To: kexec, kumagai-atsushi; +Cc: Baoquan He, vgoyal

These functions are used to parse /proc/iomem code and get memory
ranges of specific type. They are implemented in kexec-tools and
borrowed here to get the crashkernel memory range. Since crashkernel
memory range should be excluded from dumpable memory ranges.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 makedumpfile.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.h |  7 +++++
 2 files changed, 89 insertions(+)

diff --git a/makedumpfile.c b/makedumpfile.c
index 760bfd1..220570e 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -8980,6 +8980,88 @@ calculate_cyclic_buffer_size(void) {
 	return TRUE;
 }
 
+
+
+//#define CRASH_RESERVED_MEM_NR   8
+struct memory_range crash_reserved_mem[CRASH_RESERVED_MEM_NR];
+int crash_reserved_mem_nr;
+
+/*
+ * iomem_for_each_line()
+ *
+ * Iterate over each line in the file returned by proc_iomem(). If match is
+ * NULL or if the line matches with our match-pattern then call the
+ * callback if non-NULL.
+ *
+ * Return the number of lines matched.
+ */
+int iomem_for_each_line(char *match,
+			      int (*callback)(void *data,
+					      int nr,
+					      char *str,
+					      unsigned long base,
+					      unsigned long length),
+			      void *data)
+{
+	const char iomem[] = "/proc/iomem";
+	char line[BUFSIZE_FGETS];
+	FILE *fp;
+	unsigned long long start, end, size;
+	char *str;
+	int consumed;
+	int count;
+	int nr = 0;
+
+	fp = fopen(iomem, "r");
+	if (!fp) {
+		ERRMSG("Cannot open %s\n", iomem);
+		exit(1);
+	}
+
+	while(fgets(line, sizeof(line), fp) != 0) {
+		count = sscanf(line, "%Lx-%Lx : %n", &start, &end, &consumed);
+		if (count != 2)
+			continue;
+		str = line + consumed;
+		size = end - start + 1;
+		if (!match || memcmp(str, match, strlen(match)) == 0) {
+			if (callback
+			    && callback(data, nr, str, start, size) < 0) {
+				break;
+			}
+			nr++;
+		}
+	}
+
+	fclose(fp);
+
+	return nr;
+}
+
+static int crashkernel_mem_callback(void *data, int nr,
+                                          char *str,
+                                          unsigned long base,
+                                          unsigned long length)
+{
+        if (nr >= CRASH_RESERVED_MEM_NR)
+                return 1;
+
+        crash_reserved_mem[nr].start = base;
+        crash_reserved_mem[nr].end   = base + length - 1;
+        return 0;
+}
+
+int is_crashkernel_mem_reserved(void)
+{
+        int ret;
+
+        ret = iomem_for_each_line("Crash kernel\n",
+                                        crashkernel_mem_callback, NULL);
+        crash_reserved_mem_nr = ret;
+
+        return !!crash_reserved_mem_nr;
+}
+
 static struct option longopts[] = {
 	{"split", no_argument, NULL, OPT_SPLIT},
 	{"reassemble", no_argument, NULL, OPT_REASSEMBLE},
diff --git a/makedumpfile.h b/makedumpfile.h
index 9402f05..7ffa1ee 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -1452,6 +1452,13 @@ extern struct array_table	array_table;
 extern struct number_table	number_table;
 extern struct srcfile_table	srcfile_table;
 
+struct memory_range {
+        unsigned long long start, end;
+};
+
+#define CRASH_RESERVED_MEM_NR   8
+struct memory_range crash_reserved_mem[CRASH_RESERVED_MEM_NR];
+int crash_reserved_mem_nr;
 
 int readmem(int type_addr, unsigned long long addr, void *bufptr, size_t size);
 int get_str_osrelease_from_vmlinux(void);
-- 
1.8.4.2


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 3/7] preparation functions for parsing vmcoreinfo
  2014-07-11  7:15 [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
  2014-07-11  7:15 ` [PATCH 2/7] functions to get crashkernel memory range Baoquan He
@ 2014-07-11  7:16 ` Baoquan He
  2014-07-11  7:16 ` [PATCH 4/7] set vmcoreinfo for kcore Baoquan He
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 22+ messages in thread
From: Baoquan He @ 2014-07-11  7:16 UTC (permalink / raw)
  To: kexec, kumagai-atsushi; +Cc: Baoquan He, vgoyal

Add 2 preparation functions get_elf_loads and get_page_offset, later
they will be needed for parsing vmcoreinfo.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 elf_info.c     | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
 elf_info.h     |  1 +
 makedumpfile.c | 16 ++++++++++++++++
 3 files changed, 67 insertions(+)

diff --git a/elf_info.c b/elf_info.c
index b277f69..69d3fdb 100644
--- a/elf_info.c
+++ b/elf_info.c
@@ -681,6 +681,56 @@ get_elf32_ehdr(int fd, char *filename, Elf32_Ehdr *ehdr)
 	return TRUE;
 }
 
+int
+get_elf_loads(int fd, char *filename)
+{
+	int i, j, phnum, elf_format;
+	Elf64_Phdr phdr;
+
+	/*
+	 * Check ELF64 or ELF32.
+	 */
+	elf_format = check_elf_format(fd, filename, &phnum, &num_pt_loads);
+	if (elf_format == ELF64)
+		flags_memory |= MEMORY_ELF64;
+	else if (elf_format != ELF32)
+		return FALSE;
+
+	if (!num_pt_loads) {
+		ERRMSG("Can't get the number of PT_LOAD.\n");
+		return FALSE;
+	}
+
+	/*
+	 * The below file information will be used as /proc/vmcore.
+	 */
+	fd_memory   = fd;
+	name_memory = filename;
+
+	pt_loads = calloc(sizeof(struct pt_load_segment), num_pt_loads);
+	if (pt_loads == NULL) {
+		ERRMSG("Can't allocate memory for the PT_LOAD. %s\n",
+		    strerror(errno));
+		return FALSE;
+	}
+	for (i = 0, j = 0; i < phnum; i++) {
+		if (!get_phdr_memory(i, &phdr))
+			return FALSE;
+
+		if (phdr.p_type != PT_LOAD)
+			continue;
+
+		if (j >= num_pt_loads)
+			return FALSE;
+		if(!dump_Elf_load(&phdr, j))
+			return FALSE;
+		j++;
+	}
+
+	return TRUE;
+}
+
+
 /*
  * Get ELF information about /proc/vmcore.
  */
diff --git a/elf_info.h b/elf_info.h
index 801faff..263d993 100644
--- a/elf_info.h
+++ b/elf_info.h
@@ -44,6 +44,7 @@ int get_elf64_ehdr(int fd, char *filename, Elf64_Ehdr *ehdr);
 int get_elf32_ehdr(int fd, char *filename, Elf32_Ehdr *ehdr);
 int get_elf_info(int fd, char *filename);
 void free_elf_info(void);
+int get_elf_loads(int fd, char *filename);
 
 int is_elf64_memory(void);
 int is_xen_memory(void);
diff --git a/makedumpfile.c b/makedumpfile.c
index 220570e..052ed85 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -9062,6 +9062,22 @@ int is_crashkernel_mem_reserved(void)
         return !!crash_reserved_mem_nr;
 }
 
+static int get_page_offset()
+{
+#ifdef __x86_64__
+	struct utsname utsname;
+	if (uname(&utsname)) {
+		ERRMSG("Cannot get name and information about current kernel : %s", strerror(errno));
+		return FALSE;
+	}
+
+	info->kernel_version = get_kernel_version(utsname.release);
+	get_versiondep_info_x86_64();
+#endif /* x86_64 */
+
+	return TRUE;
+}
+
 static struct option longopts[] = {
 	{"split", no_argument, NULL, OPT_SPLIT},
 	{"reassemble", no_argument, NULL, OPT_REASSEMBLE},
-- 
1.8.4.2


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 4/7] set vmcoreinfo for kcore
  2014-07-11  7:15 [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
  2014-07-11  7:15 ` [PATCH 2/7] functions to get crashkernel memory range Baoquan He
  2014-07-11  7:16 ` [PATCH 3/7] preparation functions for parsing vmcoreinfo Baoquan He
@ 2014-07-11  7:16 ` Baoquan He
  2014-07-11  7:16 ` [PATCH 5/7] prepare the dump loads for kcore analysis Baoquan He
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 22+ messages in thread
From: Baoquan He @ 2014-07-11  7:16 UTC (permalink / raw)
  To: kexec, kumagai-atsushi; +Cc: Baoquan He, vgoyal

In vmcore dumping, note program of vmcoreinfo is set in elf header
of /proc/vmcore. In 1st kernel, the vmcoreinfo is also needed for
kcore analyzing. So in this patch information of vmcoreinfo is
parsed and set in offset_vmcoreinfo and size_vmcoreinfo.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 elf_info.c     | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
 elf_info.h     |  1 +
 makedumpfile.c | 29 +++++++++++++++++++++++++++++
 3 files changed, 79 insertions(+)

diff --git a/elf_info.c b/elf_info.c
index 69d3fdb..1a3e3bd 100644
--- a/elf_info.c
+++ b/elf_info.c
@@ -395,6 +395,55 @@ get_pt_note_info(void)
 	return TRUE;
 }
 
+#define UNINITIALIZED  ((ulong)(-1))
+int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len)
+{
+	int i;
+	ulong kvaddr;
+	Elf64_Nhdr *note64;
+	off_t offset;
+	char note[MAX_SIZE_NHDR];
+	int size_desc;
+	off_t offset_desc;
+
+	offset = UNINITIALIZED;
+	kvaddr = (ulong)vmcoreinfo_addr | PAGE_OFFSET;
+
+	for (i = 0; i < num_pt_loads; ++i) {
+		struct pt_load_segment *p = &pt_loads[i];
+		if ((kvaddr >= p->virt_start) && (kvaddr < p->virt_end)) {
+			offset = (off_t)(kvaddr - p->virt_start) +
+			(off_t)p->file_offset;
+			break;
+		}
+	}
+
+	if (offset == UNINITIALIZED){
+		ERRMSG("Can't seek the dump memory(%s). %s\n",
+		    name_memory, strerror(errno));
+		return FALSE;
+	}
+
+        if (lseek(fd_memory, offset, SEEK_SET) != offset){
+		ERRMSG("Can't seek the dump memory(%s). %s\n",
+		    name_memory, strerror(errno));
+		return FALSE;
+	}
+
+	if (read(fd_memory, note, MAX_SIZE_NHDR) != MAX_SIZE_NHDR){
+		ERRMSG("Can't read the dump memory(%s). %s\n",
+		    name_memory, strerror(errno));
+		return FALSE;
+	}
+
+	note64 = (Elf64_Nhdr *)note;
+	size_desc   = note_descsz(note);
+	offset_desc = offset + offset_note_desc(note);
+
+	set_vmcoreinfo(offset_desc, size_desc);
+
+	return TRUE;
+}
 
 /*
  * External functions.
diff --git a/elf_info.h b/elf_info.h
index 263d993..3ce0138 100644
--- a/elf_info.h
+++ b/elf_info.h
@@ -45,6 +45,7 @@ int get_elf32_ehdr(int fd, char *filename, Elf32_Ehdr *ehdr);
 int get_elf_info(int fd, char *filename);
 void free_elf_info(void);
 int get_elf_loads(int fd, char *filename);
+int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len);
 
 int is_elf64_memory(void);
 int is_xen_memory(void);
diff --git a/makedumpfile.c b/makedumpfile.c
index 052ed85..b67ede1 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -9078,6 +9078,35 @@ static int get_page_offset()
 	return TRUE;
 }
 
+
+/* Returns the physical address of start of crash notes buffer for a kernel. */
+static int get_sys_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len)
+{
+	char line[BUFSIZE_FGETS];
+	int count;
+	FILE *fp;
+	unsigned long long temp, temp2;
+
+	*addr = 0;
+	*len = 0;
+
+	if (!(fp = fopen("/sys/kernel/vmcoreinfo", "r")))
+		return -1;
+
+	if (!fgets(line, sizeof(line), fp))
+		ERRMSG("Cannot parse %s: %s\n", "/sys/kernel/vmcoreinfo", strerror(errno));
+	count = sscanf(line, "%Lx %Lx", &temp, &temp2);
+	if (count != 2)
+		ERRMSG("Cannot parse %s: %s\n", "/sys/kernel/vmcoreinfo", strerror(errno));
+
+	*addr = (uint64_t) temp;
+	*len = (uint64_t) temp2;
+
+	fclose(fp);
+	return 0;
+}
+
+
 static struct option longopts[] = {
 	{"split", no_argument, NULL, OPT_SPLIT},
 	{"reassemble", no_argument, NULL, OPT_REASSEMBLE},
-- 
1.8.4.2


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 5/7] prepare the dump loads for kcore analysis
  2014-07-11  7:15 [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
                   ` (2 preceding siblings ...)
  2014-07-11  7:16 ` [PATCH 4/7] set vmcoreinfo for kcore Baoquan He
@ 2014-07-11  7:16 ` Baoquan He
  2014-07-23  7:20   ` Atsushi Kumagai
  2014-07-11  7:16 ` [PATCH 6/7] implement a function to print the memory usage Baoquan He
                   ` (2 subsequent siblings)
  6 siblings, 1 reply; 22+ messages in thread
From: Baoquan He @ 2014-07-11  7:16 UTC (permalink / raw)
  To: kexec, kumagai-atsushi; +Cc: Baoquan He, vgoyal

In kcore, only  "System Ram" and "kernel text" program segments
are needed. And to be more precise, exclude the crashkernel
memory range.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 elf_info.c | 135 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 elf_info.h |   1 +
 2 files changed, 136 insertions(+)

diff --git a/elf_info.c b/elf_info.c
index 1a3e3bd..ca63d34 100644
--- a/elf_info.c
+++ b/elf_info.c
@@ -779,6 +779,141 @@ get_elf_loads(int fd, char *filename)
 	return TRUE;
 }
 
+static int exclude_segment(struct pt_load_segment **pt_loads, unsigned int	*num_pt_loads, uint64_t start, uint64_t end)
+{
+        int i, j, tidx = -1;
+	unsigned long long	vstart, vend, kvstart, kvend;
+        struct pt_load_segment temp_seg = {0};
+	kvstart = (ulong)start | PAGE_OFFSET;
+	kvend = (ulong)end | PAGE_OFFSET;
+	unsigned long size;
+
+        for (i = 0; i < (*num_pt_loads); i++) {
+                vstart = (*pt_loads)[i].virt_start;
+                vend = (*pt_loads)[i].virt_end;
+                if (kvstart <  vend && kvend > vstart) {
+                        if (kvstart != vstart && kvend != vend) {
+				/* Split load segment */
+				temp_seg.phys_start = end +1;
+				temp_seg.phys_end = (*pt_loads)[i].phys_end;
+				temp_seg.virt_start = kvend + 1;
+				temp_seg.virt_end = vend;
+				temp_seg.file_offset = (*pt_loads)[i].file_offset + temp_seg.virt_start - (*pt_loads)[i].virt_start;
+
+				(*pt_loads)[i].virt_end = kvstart - 1;
+				(*pt_loads)[i].phys_end =  start -1;
+
+				tidx = i+1;
+                        } else if (kvstart != vstart) {
+				(*pt_loads)[i].phys_end = start - 1;
+				(*pt_loads)[i].virt_end = kvstart - 1;
+                        } else {
+				(*pt_loads)[i].phys_start = end + 1;
+				(*pt_loads)[i].virt_start = kvend + 1;
+                        }
+                }
+        }
+        /* Insert split load segment, if any. */
+	if (tidx >= 0) {
+		size = (*num_pt_loads + 1) * sizeof((*pt_loads)[0]);
+		(*pt_loads) = realloc((*pt_loads), size);
+		if  (!(*pt_loads) ) {
+		    ERRMSG("Cannot realloc %ld bytes: %s\n",
+		            size + 0UL, strerror(errno));
+			exit(1);
+		}
+		for (j = (*num_pt_loads - 1); j >= tidx; j--)
+		        (*pt_loads)[j+1] = (*pt_loads)[j];
+		(*pt_loads)[tidx] = temp_seg;
+		(*num_pt_loads)++;
+        }
+        return 0;
+}
+
+static int
+process_dump_load(struct pt_load_segment	*pls)
+{
+	unsigned long long paddr;
+
+	paddr = vaddr_to_paddr(pls->virt_start);
+	pls->phys_start  = paddr;
+	pls->phys_end    = paddr + (pls->virt_end - pls->virt_start);
+	DEBUG_MSG("process_dump_load\n");
+	DEBUG_MSG("  phys_start : %llx\n", pls->phys_start);
+	DEBUG_MSG("  phys_end   : %llx\n", pls->phys_end);
+	DEBUG_MSG("  virt_start : %llx\n", pls->virt_start);
+	DEBUG_MSG("  virt_end   : %llx\n", pls->virt_end);
+
+	return TRUE;
+}
+
+int get_kcore_dump_loads()
+{
+	struct pt_load_segment	*pls;
+	int i, j, loads=0;
+	unsigned long long paddr;
+
+	for (i = 0; i < num_pt_loads; ++i) {
+		struct pt_load_segment *p = &pt_loads[i];
+		if (is_vmalloc_addr(p->virt_start))
+			continue;
+		loads++;
+	}
+
+	pls = calloc(sizeof(struct pt_load_segment), loads);
+	if (pls == NULL) {
+		ERRMSG("Can't allocate memory for the PT_LOAD. %s\n",
+		    strerror(errno));
+		return FALSE;
+	}
+
+	for (i = 0, j=0; i < num_pt_loads; ++i) {
+		struct pt_load_segment *p = &pt_loads[i];
+		if (is_vmalloc_addr(p->virt_start))
+			continue;
+		if (j >= loads)
+			return FALSE;
+
+		if (j == 0) {
+			offset_pt_load_memory = p->file_offset;
+			if (offset_pt_load_memory == 0) {
+				ERRMSG("Can't get the offset of page data.\n");
+				return FALSE;
+			}
+		}
+
+		pls[j] = *p;
+		process_dump_load(&pls[j]);
+		j++;
+	}
+
+	free(pt_loads);
+	pt_loads = pls;
+	num_pt_loads = loads;
+
+	for (i=0; i<crash_reserved_mem_nr; i++)
+	{
+		exclude_segment(&pt_loads, &num_pt_loads, crash_reserved_mem[i].start, crash_reserved_mem[i].end);
+	}
+
+	max_file_offset = 0;
+	for (i = 0; i < num_pt_loads; ++i) {
+		struct pt_load_segment *p = &pt_loads[i];
+		max_file_offset = MAX(max_file_offset,
+				      p->file_offset + p->phys_end - p->phys_start);
+	}
+
+	for (i = 0; i < num_pt_loads; ++i) {
+		struct pt_load_segment *p = &pt_loads[i];
+		DEBUG_MSG("LOAD (%d)\n", i);
+		DEBUG_MSG("  phys_start : %llx\n", p->phys_start);
+		DEBUG_MSG("  phys_end   : %llx\n", p->phys_end);
+		DEBUG_MSG("  virt_start : %llx\n", p->virt_start);
+		DEBUG_MSG("  virt_end   : %llx\n", p->virt_end);
+	}
+
+	return TRUE;
+}
 
 /*
  * Get ELF information about /proc/vmcore.
diff --git a/elf_info.h b/elf_info.h
index 3ce0138..ba27fdf 100644
--- a/elf_info.h
+++ b/elf_info.h
@@ -46,6 +46,7 @@ int get_elf_info(int fd, char *filename);
 void free_elf_info(void);
 int get_elf_loads(int fd, char *filename);
 int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len);
+int get_kcore_dump_loads();
 
 int is_elf64_memory(void);
 int is_xen_memory(void);
-- 
1.8.4.2


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 6/7] implement a function to print the memory usage
  2014-07-11  7:15 [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
                   ` (3 preceding siblings ...)
  2014-07-11  7:16 ` [PATCH 5/7] prepare the dump loads for kcore analysis Baoquan He
@ 2014-07-11  7:16 ` Baoquan He
  2014-07-11  7:16 ` [PATCH 7/7] add a new interface to show the memory usage of 1st kernel Baoquan He
  2014-07-11 14:19 ` [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Vivek Goyal
  6 siblings, 0 replies; 22+ messages in thread
From: Baoquan He @ 2014-07-11  7:16 UTC (permalink / raw)
  To: kexec, kumagai-atsushi; +Cc: Baoquan He, vgoyal

Introduce print_mem_usage to print the result of analysis of /proc/kcore.
The page number of memory in different use are printed.

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 makedumpfile.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/makedumpfile.c b/makedumpfile.c
index b67ede1..a170dd3 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -7830,6 +7830,46 @@ print_report(void)
 	REPORT_MSG("\n");
 }
 
+static void
+print_mem_usage(void)
+{
+	mdf_pfn_t pfn_original, pfn_excluded, shrinking;
+
+	/*
+	* /proc/vmcore doesn't contain the memory hole area.
+	*/
+	pfn_original = info->max_mapnr - pfn_memhole;
+
+	pfn_excluded = pfn_zero + pfn_cache + pfn_cache_private
+	    + pfn_user + pfn_free + pfn_hwpoison;
+	shrinking = (pfn_original - pfn_excluded) * 100;
+	shrinking = shrinking / pfn_original;
+
+	MSG("\n");
+	MSG("Page number of memory in different use\n");
+	MSG("--------------------------------------------------\n");
+	MSG("TYPE			PAGES			EXCLUDABLE	DESCRIPTION\n");
+
+	MSG("pfn_zero		0x%016llx	yes		Pages filled with zero\n", pfn_zero);
+	MSG("pfn_cache		0x%016llx	yes		Cache pages\n", pfn_cache);
+	MSG("pfn_cache_private	0x%016llx	yes		Cache pages + private\n",
+	    pfn_cache_private);
+	MSG("pfn_user		0x%016llx	yes		User process data pages\n", pfn_user);
+	MSG("pfn_free		0x%016llx	yes		Free pages\n", pfn_free);
+	MSG("pfn_hwpoison		0x%016llx	yes		Hwpoison pages\n", pfn_hwpoison);
+	MSG("pfn_kernel_data		0x%016llx	no		Dumpable kernel data \n",
+	    pfn_original - pfn_excluded);
+
+	MSG("\n");
+
+	MSG("Total pages on system:	0x%016llx\n", pfn_original);
+	MSG("Excludable pages:	0x%016llx\n", pfn_excluded);
+	MSG("Memory Hole: 		0x%016llx\n", pfn_memhole);
+	MSG("--------------------------------------------------\n");
+	MSG("Total pages:		0x%016llx\n", info->max_mapnr);
+	MSG("\n");
+}
+
 int
 writeout_dumpfile(void)
 {
-- 
1.8.4.2


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH 7/7] add a new interface to show the memory usage of 1st kernel
  2014-07-11  7:15 [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
                   ` (4 preceding siblings ...)
  2014-07-11  7:16 ` [PATCH 6/7] implement a function to print the memory usage Baoquan He
@ 2014-07-11  7:16 ` Baoquan He
  2014-07-11  7:27   ` [PATCH v2] " Baoquan He
                     ` (3 more replies)
  2014-07-11 14:19 ` [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Vivek Goyal
  6 siblings, 4 replies; 22+ messages in thread
From: Baoquan He @ 2014-07-11  7:16 UTC (permalink / raw)
  To: kexec, kumagai-atsushi; +Cc: Baoquan He, vgoyal

Recently people complained that they don't decide how much disk size
need be reserved for kdump storing. E.g there are lots of machines
with different memory size, if the memory usage information of current
system can be shown, that can help them to make an estimate how much
storage space need be reserved.

In this patch, a new interface is added into makedumpfile. With the
help of this, people can know the page number of memory in different
use. The implementation is analyzing the "System Ram" and "kernel text"
program segment of /proc/kcore excluding the crashkernel range, then
calculating the page number of different kind per vmcoreinfo.

The print is like below:
->$ ./makedumpfile  --mem-usage  /proc/kcore
Excluding unnecessary pages        : [100.0 %] |

Page number of memory in different use
--------------------------------------------------
TYPE			PAGES			EXCLUDABLE	DESCRIPTION
pfn_zero		0x0000000000000000	yes		Pages filled with zero
pfn_cache		0x000000000002b19f	yes		Cache pages
pfn_cache_private	0x0000000000042526	yes		Cache pages + private
pfn_user		0x0000000000026bc3	yes		User process data pages
pfn_free		0x0000000000133f79	yes		Free pages
pfn_hwpoison		0x0000000000000000	yes		Hwpoison pages
pfn_kernel_data		0x000000000001dd56	no		Dumpable kernel data

Total pages on system:	0x00000000001e5f57
Excludable pages:	0x00000000001c8201
Memory Hole: 		0x00000000000386a9
--------------------------------------------------
Total pages:		0x000000000021e600

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 makedumpfile.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.h |  2 ++
 2 files changed, 73 insertions(+)

diff --git a/makedumpfile.c b/makedumpfile.c
index a170dd3..b281d73 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -8904,6 +8904,13 @@ check_param_for_creating_dumpfile(int argc, char *argv[])
 		 */
 		info->name_memory   = argv[optind];
 
+	} else if ((argc == optind + 1) && info->flag_mem_usage) {
+		/*
+		* Parameter for showing the page number of memory
+		* in different use from.
+		*/
+		info->name_memory   = argv[optind];
+
 	} else
 		return FALSE;
 
@@ -9146,6 +9153,54 @@ static int get_sys_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len)
 	return 0;
 }
 
+int show_mem_usage(void)
+{
+        uint64_t vmcoreinfo_addr, vmcoreinfo_len;
+
+        if (!is_crashkernel_mem_reserved()) {
+                ERRMSG("No memory is reserved for crashkenrel!\n");
+                return FALSE;
+        }
+
+        if (!get_page_offset())
+                return FALSE;
+
+        if (!open_dump_memory())
+                return FALSE;
+
+        if (!get_elf_loads(info->fd_memory, info->name_memory))
+                return FALSE;
+
+        if (get_sys_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
+                return FALSE;
+
+        if (!set_kcore_vmcoreinfo(vmcoreinfo_addr, vmcoreinfo_len))
+                return FALSE;
+
+        if (!get_kcore_dump_loads())
+                return FALSE;
+
+        if (!initial())
+                return FALSE;
+
+        if (!info->flag_cyclic)
+                info->flag_cyclic = TRUE;
+
+        if (!prepare_bitmap2_buffer_cyclic())
+                return FALSE;
+
+        info->num_dumpable = get_num_dumpable_cyclic();
+
+	free_bitmap2_buffer_cyclic();
+
+        print_mem_usage();
+
+        if (!close_files_for_creating_dumpfile())
+                return FALSE;
+
+        return TRUE;
+}
+
 
 static struct option longopts[] = {
 	{"split", no_argument, NULL, OPT_SPLIT},
@@ -9163,6 +9218,7 @@ static struct option longopts[] = {
 	{"cyclic-buffer", required_argument, NULL, OPT_CYCLIC_BUFFER},
 	{"eppic", required_argument, NULL, OPT_EPPIC},
 	{"non-mmap", no_argument, NULL, OPT_NON_MMAP},
+	{"mem-usage", no_argument, NULL, OPT_MEM_USAGE},
 	{0, 0, 0, 0}
 };
 
@@ -9254,6 +9310,9 @@ main(int argc, char *argv[])
 		case OPT_DUMP_DMESG:
 			info->flag_dmesg = 1;
 			break;
+		case OPT_MEM_USAGE:
+                       info->flag_mem_usage = 1;
+                       break;
 		case OPT_COMPRESS_SNAPPY:
 			info->flag_compress = DUMP_DH_COMPRESSED_SNAPPY;
 			break;
@@ -9394,6 +9453,18 @@ main(int argc, char *argv[])
 
 		MSG("\n");
 		MSG("The dmesg log is saved to %s.\n", info->name_dumpfile);
+	} else if (info->flag_mem_usage) {
+		if (!check_param_for_creating_dumpfile(argc, argv)) {
+			MSG("Commandline parameter is invalid.\n");
+			MSG("Try `makedumpfile --help' for more information.\n");
+			goto out;
+		}
+
+		if (!show_mem_usage())
+			goto out;
+
+		MSG("\n");
+		MSG("Showing page number of memory in different use successfully.\n");
 	} else {
 		if (!check_param_for_creating_dumpfile(argc, argv)) {
 			MSG("Commandline parameter is invalid.\n");
diff --git a/makedumpfile.h b/makedumpfile.h
index 7ffa1ee..7b537c7 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -910,6 +910,7 @@ struct DumpInfo {
 	int		flag_force;	     /* overwrite existing stuff */
 	int		flag_exclude_xen_dom;/* exclude Domain-U from xen-kdump */
 	int             flag_dmesg;          /* dump the dmesg log out of the vmcore file */
+	int             flag_mem_usage;  /*show the page number of memory in different use*/
 	int		flag_use_printk_log; /* did we read printk_log symbol name? */
 	int		flag_nospace;	     /* the flag of "No space on device" error */
 	int		flag_vmemmap;        /* kernel supports vmemmap address space */
@@ -1771,6 +1772,7 @@ struct elf_prstatus {
 #define OPT_CYCLIC_BUFFER       OPT_START+11
 #define OPT_EPPIC               OPT_START+12
 #define OPT_NON_MMAP            OPT_START+13
+#define OPT_MEM_USAGE            OPT_START+14
 
 /*
  * Function Prototype.
-- 
1.8.4.2


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [PATCH v2] add a new interface to show the memory usage of 1st kernel
  2014-07-11  7:16 ` [PATCH 7/7] add a new interface to show the memory usage of 1st kernel Baoquan He
@ 2014-07-11  7:27   ` Baoquan He
  2014-07-23  7:20     ` Atsushi Kumagai
  2014-07-11  7:35   ` [PATCH 7/7] " Baoquan He
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 22+ messages in thread
From: Baoquan He @ 2014-07-11  7:27 UTC (permalink / raw)
  To: kexec, kumagai-atsushi; +Cc: vgoyal

Recently people complained that they don't know how to decide how
much disk size need be reserved for kdump. E.g there are lots of
machines with different memory size, if the memory usage information
of current system can be shown, that can help them to make an estimate
how much storage space need be reserved.

In this patch, a new interface is added into makedumpfile. By the
help of this, people can know the page number of memory in different
use. The implementation is analyzing the "System Ram" and "kernel text"
program segment of /proc/kcore excluding the crashkernel range, then
calculating the page number of different kind per vmcoreinfo.

The print is like below:
->$ ./makedumpfile  --mem-usage  /proc/kcore
Excluding unnecessary pages        : [100.0 %] |

Page number of memory in different use
--------------------------------------------------
TYPE			PAGES			EXCLUDABLE	DESCRIPTION
pfn_zero		0x0000000000000000	yes		Pages filled with zero
pfn_cache		0x000000000002b19f	yes		Cache pages
pfn_cache_private	0x0000000000042526	yes		Cache pages + private
pfn_user		0x0000000000026bc3	yes		User process data pages
pfn_free		0x0000000000133f79	yes		Free pages
pfn_hwpoison	0x0000000000000000	yes		Hwpoison pages
pfn_kernel_data	0x000000000001dd56	no		Dumpable kernel data

Total pages on system:	0x00000000001e5f57
Excludable pages:	0x00000000001c8201
Memory Hole: 		0x00000000000386a9
--------------------------------------------------
Total pages:		0x000000000021e600

Signed-off-by: Baoquan He <bhe@redhat.com>
---
 makedumpfile.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.h |  2 ++
 2 files changed, 77 insertions(+)

diff --git a/makedumpfile.c b/makedumpfile.c
index a170dd3..95790be 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -8904,6 +8904,13 @@ check_param_for_creating_dumpfile(int argc, char *argv[])
 		 */
 		info->name_memory   = argv[optind];
 
+	} else if ((argc == optind + 1) && info->flag_mem_usage) {
+		/*
+		* Parameter for showing the page number of memory
+		* in different use from.
+		*/
+		info->name_memory   = argv[optind];
+
 	} else
 		return FALSE;
 
@@ -9146,6 +9153,58 @@ static int get_sys_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len)
 	return 0;
 }
 
+int show_mem_usage(void)
+{
+        uint64_t vmcoreinfo_addr, vmcoreinfo_len;
+
+        if (!is_crashkernel_mem_reserved()) {
+                ERRMSG("No memory is reserved for crashkenrel!\n");
+                return FALSE;
+        }
+
+
+        if (!info->flag_cyclic)
+                info->flag_cyclic = TRUE;
+
+	info->dump_level = MAX_DUMP_LEVEL;
+
+        if (!get_page_offset())
+                return FALSE;
+
+        if (!open_dump_memory())
+                return FALSE;
+
+        if (!get_elf_loads(info->fd_memory, info->name_memory))
+                return FALSE;
+
+        if (get_sys_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
+                return FALSE;
+
+        if (!set_kcore_vmcoreinfo(vmcoreinfo_addr, vmcoreinfo_len))
+                return FALSE;
+
+        if (!get_kcore_dump_loads())
+                return FALSE;
+
+        if (!initial())
+                return FALSE;
+
+
+        if (!prepare_bitmap2_buffer_cyclic())
+                return FALSE;
+
+        info->num_dumpable = get_num_dumpable_cyclic();
+
+	free_bitmap2_buffer_cyclic();
+
+        print_mem_usage();
+
+        if (!close_files_for_creating_dumpfile())
+                return FALSE;
+
+        return TRUE;
+}
+
 
 static struct option longopts[] = {
 	{"split", no_argument, NULL, OPT_SPLIT},
@@ -9163,6 +9222,7 @@ static struct option longopts[] = {
 	{"cyclic-buffer", required_argument, NULL, OPT_CYCLIC_BUFFER},
 	{"eppic", required_argument, NULL, OPT_EPPIC},
 	{"non-mmap", no_argument, NULL, OPT_NON_MMAP},
+	{"mem-usage", no_argument, NULL, OPT_MEM_USAGE},
 	{0, 0, 0, 0}
 };
 
@@ -9254,6 +9314,9 @@ main(int argc, char *argv[])
 		case OPT_DUMP_DMESG:
 			info->flag_dmesg = 1;
 			break;
+		case OPT_MEM_USAGE:
+                       info->flag_mem_usage = 1;
+                       break;
 		case OPT_COMPRESS_SNAPPY:
 			info->flag_compress = DUMP_DH_COMPRESSED_SNAPPY;
 			break;
@@ -9394,6 +9457,18 @@ main(int argc, char *argv[])
 
 		MSG("\n");
 		MSG("The dmesg log is saved to %s.\n", info->name_dumpfile);
+	} else if (info->flag_mem_usage) {
+		if (!check_param_for_creating_dumpfile(argc, argv)) {
+			MSG("Commandline parameter is invalid.\n");
+			MSG("Try `makedumpfile --help' for more information.\n");
+			goto out;
+		}
+
+		if (!show_mem_usage())
+			goto out;
+
+		MSG("\n");
+		MSG("Showing page number of memory in different use successfully.\n");
 	} else {
 		if (!check_param_for_creating_dumpfile(argc, argv)) {
 			MSG("Commandline parameter is invalid.\n");
diff --git a/makedumpfile.h b/makedumpfile.h
index 7ffa1ee..7b537c7 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -910,6 +910,7 @@ struct DumpInfo {
 	int		flag_force;	     /* overwrite existing stuff */
 	int		flag_exclude_xen_dom;/* exclude Domain-U from xen-kdump */
 	int             flag_dmesg;          /* dump the dmesg log out of the vmcore file */
+	int             flag_mem_usage;  /*show the page number of memory in different use*/
 	int		flag_use_printk_log; /* did we read printk_log symbol name? */
 	int		flag_nospace;	     /* the flag of "No space on device" error */
 	int		flag_vmemmap;        /* kernel supports vmemmap address space */
@@ -1771,6 +1772,7 @@ struct elf_prstatus {
 #define OPT_CYCLIC_BUFFER       OPT_START+11
 #define OPT_EPPIC               OPT_START+12
 #define OPT_NON_MMAP            OPT_START+13
+#define OPT_MEM_USAGE            OPT_START+14
 
 /*
  * Function Prototype.
-- 
1.9.3


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* Re: [PATCH 7/7] add a new interface to show the memory usage of 1st kernel
  2014-07-11  7:16 ` [PATCH 7/7] add a new interface to show the memory usage of 1st kernel Baoquan He
  2014-07-11  7:27   ` [PATCH v2] " Baoquan He
@ 2014-07-11  7:35   ` Baoquan He
  2014-07-11 14:26   ` Vivek Goyal
  2014-07-11 14:35   ` Vivek Goyal
  3 siblings, 0 replies; 22+ messages in thread
From: Baoquan He @ 2014-07-11  7:35 UTC (permalink / raw)
  To: kexec, kumagai-atsushi; +Cc: vgoyal

Hi,

In this patch, I set info->dump_level=MAX_DUMP_LEVEL, and
info->flag_cyclic=TRUE; With MAX_DUMP_LEVEL all kinds of memory can be
calculated. And under cyclic mode, function get_num_dumpable_cyclic() is
ready to do the page number calculation of memory in different use.

There's miss in [patch 7/7 v1], please reivew [patch 7/7 v2].

Thanks
Baoquan

On 07/11/14 at 03:16pm, Baoquan He wrote:
> Recently people complained that they don't decide how much disk size
> need be reserved for kdump storing. E.g there are lots of machines
> with different memory size, if the memory usage information of current
> system can be shown, that can help them to make an estimate how much
> storage space need be reserved.
> 
> In this patch, a new interface is added into makedumpfile. With the
> help of this, people can know the page number of memory in different
> use. The implementation is analyzing the "System Ram" and "kernel text"
> program segment of /proc/kcore excluding the crashkernel range, then
> calculating the page number of different kind per vmcoreinfo.
> 
> The print is like below:
> ->$ ./makedumpfile  --mem-usage  /proc/kcore
> Excluding unnecessary pages        : [100.0 %] |
> 
> Page number of memory in different use
> --------------------------------------------------
> TYPE			PAGES			EXCLUDABLE	DESCRIPTION
> pfn_zero		0x0000000000000000	yes		Pages filled with zero
> pfn_cache		0x000000000002b19f	yes		Cache pages
> pfn_cache_private	0x0000000000042526	yes		Cache pages + private
> pfn_user		0x0000000000026bc3	yes		User process data pages
> pfn_free		0x0000000000133f79	yes		Free pages
> pfn_hwpoison		0x0000000000000000	yes		Hwpoison pages
> pfn_kernel_data		0x000000000001dd56	no		Dumpable kernel data
> 
> Total pages on system:	0x00000000001e5f57
> Excludable pages:	0x00000000001c8201
> Memory Hole: 		0x00000000000386a9
> --------------------------------------------------

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic
  2014-07-11  7:15 [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
                   ` (5 preceding siblings ...)
  2014-07-11  7:16 ` [PATCH 7/7] add a new interface to show the memory usage of 1st kernel Baoquan He
@ 2014-07-11 14:19 ` Vivek Goyal
  2014-07-11 14:28   ` Baoquan He
  6 siblings, 1 reply; 22+ messages in thread
From: Vivek Goyal @ 2014-07-11 14:19 UTC (permalink / raw)
  To: Baoquan He; +Cc: kumagai-atsushi, kexec

Hi Bao,

There is no patch 0 describing what this patch series is all about and
what it is fixing?

Thanks
Vivek

On Fri, Jul 11, 2014 at 03:15:58PM +0800, Baoquan He wrote:
> This is a code bug. In initialize_2nd_bitmap_cyclic pfn_memhole is
> calculated, however it's not initialized before that. If an available
> pfn_memhole is wanted after get_num_dumpable_cyclic invocation,
> initializing pfn_memhole in get_num_dumpable_cyclic is necessary.
> 
> Signed-off-by: Baoquan He <bhe@redhat.com>
> ---
>  makedumpfile.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/makedumpfile.c b/makedumpfile.c
> index 3884aa5..760bfd1 100644
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -5588,6 +5588,8 @@ get_num_dumpable_cyclic(void)
>  	mdf_pfn_t pfn, num_dumpable=0;
>  	struct cycle cycle = {0};
>  
> +	pfn_memhole = info->max_mapnr;
> +
>  	for_each_cycle(0, info->max_mapnr, &cycle)
>  	{
>  		if (!exclude_unnecessary_pages_cyclic(&cycle))
> -- 
> 1.8.4.2

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 7/7] add a new interface to show the memory usage of 1st kernel
  2014-07-11  7:16 ` [PATCH 7/7] add a new interface to show the memory usage of 1st kernel Baoquan He
  2014-07-11  7:27   ` [PATCH v2] " Baoquan He
  2014-07-11  7:35   ` [PATCH 7/7] " Baoquan He
@ 2014-07-11 14:26   ` Vivek Goyal
  2014-07-11 14:35     ` Baoquan He
  2014-07-11 14:35   ` Vivek Goyal
  3 siblings, 1 reply; 22+ messages in thread
From: Vivek Goyal @ 2014-07-11 14:26 UTC (permalink / raw)
  To: Baoquan He; +Cc: kumagai-atsushi, kexec

On Fri, Jul 11, 2014 at 03:16:04PM +0800, Baoquan He wrote:
> Recently people complained that they don't decide how much disk size
> need be reserved for kdump storing. E.g there are lots of machines
> with different memory size, if the memory usage information of current
> system can be shown, that can help them to make an estimate how much
> storage space need be reserved.
> 
> In this patch, a new interface is added into makedumpfile. With the
> help of this, people can know the page number of memory in different
> use. The implementation is analyzing the "System Ram" and "kernel text"
> program segment of /proc/kcore excluding the crashkernel range, then
> calculating the page number of different kind per vmcoreinfo.
> 
> The print is like below:
> ->$ ./makedumpfile  --mem-usage  /proc/kcore
> Excluding unnecessary pages        : [100.0 %] |
> 
> Page number of memory in different use

Hi Bao,

How about priting number of pages in decimal numbers. Humans read decimal
numbers much better.


> --------------------------------------------------
> TYPE			PAGES			EXCLUDABLE	DESCRIPTION
> pfn_zero		0x0000000000000000	yes		Pages filled with zero

I am wondering if we display TYPE of page as follows. Will it be more
redable

ZERO
CACHE
CACHE_PRIVATE
..
..

> pfn_cache		0x000000000002b19f	yes		Cache pages
> pfn_cache_private	0x0000000000042526	yes		Cache pages + private
> pfn_user		0x0000000000026bc3	yes		User process data pages

How about calling them just "User process pages" and not "user process
data pages" I am assuming that they could contain text too.

> pfn_free		0x0000000000133f79	yes		Free pages
> pfn_hwpoison		0x0000000000000000	yes		Hwpoison pages
> pfn_kernel_data		0x000000000001dd56	no		Dumpable kernel data
> 
> Total pages on system:	0x00000000001e5f57
> Excludable pages:	0x00000000001c8201
> Memory Hole: 		0x00000000000386a9

What is "Memory Hole" ?

> --------------------------------------------------
> Total pages:		0x000000000021e600

How this total pages is different from "Total pages on system"?

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic
  2014-07-11 14:19 ` [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Vivek Goyal
@ 2014-07-11 14:28   ` Baoquan He
  0 siblings, 0 replies; 22+ messages in thread
From: Baoquan He @ 2014-07-11 14:28 UTC (permalink / raw)
  To: Vivek Goyal; +Cc: kumagai-atsushi, kexec

On 07/11/14 at 10:19am, Vivek Goyal wrote:
> Hi Bao,
> 
> There is no patch 0 describing what this patch series is all about and
> what it is fixing?

Sorry, I just remembered this after patches had been sent out. But much
information has been added into the main patch [patch 7/7].

Will make a cover letter in next post.

Thanks
Baoquan

> 
> Thanks
> Vivek
> 
> On Fri, Jul 11, 2014 at 03:15:58PM +0800, Baoquan He wrote:
> > This is a code bug. In initialize_2nd_bitmap_cyclic pfn_memhole is
> > calculated, however it's not initialized before that. If an available
> > pfn_memhole is wanted after get_num_dumpable_cyclic invocation,
> > initializing pfn_memhole in get_num_dumpable_cyclic is necessary.
> > 
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > ---
> >  makedumpfile.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/makedumpfile.c b/makedumpfile.c
> > index 3884aa5..760bfd1 100644
> > --- a/makedumpfile.c
> > +++ b/makedumpfile.c
> > @@ -5588,6 +5588,8 @@ get_num_dumpable_cyclic(void)
> >  	mdf_pfn_t pfn, num_dumpable=0;
> >  	struct cycle cycle = {0};
> >  
> > +	pfn_memhole = info->max_mapnr;
> > +
> >  	for_each_cycle(0, info->max_mapnr, &cycle)
> >  	{
> >  		if (!exclude_unnecessary_pages_cyclic(&cycle))
> > -- 
> > 1.8.4.2

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 7/7] add a new interface to show the memory usage of 1st kernel
  2014-07-11  7:16 ` [PATCH 7/7] add a new interface to show the memory usage of 1st kernel Baoquan He
                     ` (2 preceding siblings ...)
  2014-07-11 14:26   ` Vivek Goyal
@ 2014-07-11 14:35   ` Vivek Goyal
  2014-07-11 14:39     ` Baoquan He
  3 siblings, 1 reply; 22+ messages in thread
From: Vivek Goyal @ 2014-07-11 14:35 UTC (permalink / raw)
  To: Baoquan He; +Cc: kumagai-atsushi, kexec

On Fri, Jul 11, 2014 at 03:16:04PM +0800, Baoquan He wrote:
> Recently people complained that they don't decide how much disk size
> need be reserved for kdump storing. E.g there are lots of machines
> with different memory size, if the memory usage information of current
> system can be shown, that can help them to make an estimate how much
> storage space need be reserved.
> 
> In this patch, a new interface is added into makedumpfile. With the
> help of this, people can know the page number of memory in different
> use. The implementation is analyzing the "System Ram" and "kernel text"
> program segment of /proc/kcore excluding the crashkernel range, then
> calculating the page number of different kind per vmcoreinfo.
> 
> The print is like below:
> ->$ ./makedumpfile  --mem-usage  /proc/kcore
> Excluding unnecessary pages        : [100.0 %] |
> 
> Page number of memory in different use
> --------------------------------------------------
> TYPE			PAGES			EXCLUDABLE	DESCRIPTION
> pfn_zero		0x0000000000000000	yes		Pages filled with zero
> pfn_cache		0x000000000002b19f	yes		Cache pages
> pfn_cache_private	0x0000000000042526	yes		Cache pages + private
> pfn_user		0x0000000000026bc3	yes		User process data pages
> pfn_free		0x0000000000133f79	yes		Free pages
> pfn_hwpoison		0x0000000000000000	yes		Hwpoison pages

Is there a need to display hwpoison pages? I think they are excluded by
default. Otherwise reading them might kill makedumpfile process.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 7/7] add a new interface to show the memory usage of 1st kernel
  2014-07-11 14:26   ` Vivek Goyal
@ 2014-07-11 14:35     ` Baoquan He
  2014-07-11 14:44       ` Vivek Goyal
  0 siblings, 1 reply; 22+ messages in thread
From: Baoquan He @ 2014-07-11 14:35 UTC (permalink / raw)
  To: Vivek Goyal; +Cc: kumagai-atsushi, kexec

On 07/11/14 at 10:26am, Vivek Goyal wrote:
> On Fri, Jul 11, 2014 at 03:16:04PM +0800, Baoquan He wrote:

> Hi Bao,
> 
> How about priting number of pages in decimal numbers. Humans read decimal
> numbers much better.

That's fine too. I can change it to decimal number. Just think that
maybe it's mainly used by script.


> 
> 
> > --------------------------------------------------
> > TYPE			PAGES			EXCLUDABLE	DESCRIPTION
> > pfn_zero		0x0000000000000000	yes		Pages filled with zero
> 
> I am wondering if we display TYPE of page as follows. Will it be more
> redable

OK, will change.

> 
> ZERO
> CACHE
> CACHE_PRIVATE
> ..
> ..
> 
> > pfn_cache		0x000000000002b19f	yes		Cache pages
> > pfn_cache_private	0x0000000000042526	yes		Cache pages + private
> > pfn_user		0x0000000000026bc3	yes		User process data pages
> 
> How about calling them just "User process pages" and not "user process
> data pages" I am assuming that they could contain text too.

This function is based on the print_report() which is in makedumpfile.
It has been defined like these already. But I will change this according
reviewer's comments. After all, they are different.

> 
> > pfn_free		0x0000000000133f79	yes		Free pages
> > pfn_hwpoison		0x0000000000000000	yes		Hwpoison pages
> > pfn_kernel_data		0x000000000001dd56	no		Dumpable kernel data
> > 
> > Total pages on system:	0x00000000001e5f57
> > Excludable pages:	0x00000000001c8201
> > Memory Hole: 		0x00000000000386a9
> 
> What is "Memory Hole" ?

That areas which are between "System Ram".

> 
> > --------------------------------------------------
> > Total pages:		0x000000000021e600
> 
> How this total pages is different from "Total pages on system"?

"Total pages on system" is all physical pages without hole. "Total pages"
is equal to the max_pfn in current system. This is got from the
print_report() too. It could be removed if people think it's useless.

> 
> Thanks
> Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 7/7] add a new interface to show the memory usage of 1st kernel
  2014-07-11 14:35   ` Vivek Goyal
@ 2014-07-11 14:39     ` Baoquan He
  2014-07-11 14:46       ` Vivek Goyal
  0 siblings, 1 reply; 22+ messages in thread
From: Baoquan He @ 2014-07-11 14:39 UTC (permalink / raw)
  To: Vivek Goyal; +Cc: kumagai-atsushi, kexec

On 07/11/14 at 10:35am, Vivek Goyal wrote:
> On Fri, Jul 11, 2014 at 03:16:04PM +0800, Baoquan He wrote:
> > ->$ ./makedumpfile  --mem-usage  /proc/kcore
> > Excluding unnecessary pages        : [100.0 %] |
> > 
> > Page number of memory in different use
> > --------------------------------------------------
> > TYPE			PAGES			EXCLUDABLE	DESCRIPTION
> > pfn_zero		0x0000000000000000	yes		Pages filled with zero
> > pfn_cache		0x000000000002b19f	yes		Cache pages
> > pfn_cache_private	0x0000000000042526	yes		Cache pages + private
> > pfn_user		0x0000000000026bc3	yes		User process data pages
> > pfn_free		0x0000000000133f79	yes		Free pages
> > pfn_hwpoison		0x0000000000000000	yes		Hwpoison pages
> 
> Is there a need to display hwpoison pages? I think they are excluded by
> default. Otherwise reading them might kill makedumpfile process.

You are right, hwpoison pages are excluded by default. But it truly
calculated in makedumpfile. I will change it as non-excludable like
below:

TYPE			PAGES			EXCLUDABLE	DESCRIPTION
pfn_hwpoison		0x0000000000000000	No		Hwpoison pages

> 
> Thanks
> Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 7/7] add a new interface to show the memory usage of 1st kernel
  2014-07-11 14:35     ` Baoquan He
@ 2014-07-11 14:44       ` Vivek Goyal
  0 siblings, 0 replies; 22+ messages in thread
From: Vivek Goyal @ 2014-07-11 14:44 UTC (permalink / raw)
  To: Baoquan He; +Cc: kumagai-atsushi, kexec

On Fri, Jul 11, 2014 at 10:35:30PM +0800, Baoquan He wrote:

[..]
> > How about calling them just "User process pages" and not "user process
> > data pages" I am assuming that they could contain text too.
> 
> This function is based on the print_report() which is in makedumpfile.
> It has been defined like these already. But I will change this according
> reviewer's comments. After all, they are different.

Actually notation should match what's in makedumpfile man page. So that
a user can easily associate dump filtering levels with pages here.

> 
> > 
> > > pfn_free		0x0000000000133f79	yes		Free pages
> > > pfn_hwpoison		0x0000000000000000	yes		Hwpoison pages
> > > pfn_kernel_data		0x000000000001dd56	no		Dumpable kernel data
> > > 
> > > Total pages on system:	0x00000000001e5f57
> > > Excludable pages:	0x00000000001c8201
> > > Memory Hole: 		0x00000000000386a9
> > 
> > What is "Memory Hole" ?
> 
> That areas which are between "System Ram".

I think we should remove it from output. We are not concerned where memory
holes are. One can look up /proc/iomem to figure out where memory holes
are.

> 
> > 
> > > --------------------------------------------------
> > > Total pages:		0x000000000021e600
> > 
> > How this total pages is different from "Total pages on system"?
> 
> "Total pages on system" is all physical pages without hole. "Total pages"
> is equal to the max_pfn in current system. This is got from the
> print_report() too. It could be removed if people think it's useless.

We are just interested in total pages without memory hole. And can
remove total pages with memory hole.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 7/7] add a new interface to show the memory usage of 1st kernel
  2014-07-11 14:39     ` Baoquan He
@ 2014-07-11 14:46       ` Vivek Goyal
  2014-07-14  5:22         ` Baoquan He
  0 siblings, 1 reply; 22+ messages in thread
From: Vivek Goyal @ 2014-07-11 14:46 UTC (permalink / raw)
  To: Baoquan He; +Cc: kumagai-atsushi, kexec

On Fri, Jul 11, 2014 at 10:39:45PM +0800, Baoquan He wrote:
> On 07/11/14 at 10:35am, Vivek Goyal wrote:
> > On Fri, Jul 11, 2014 at 03:16:04PM +0800, Baoquan He wrote:
> > > ->$ ./makedumpfile  --mem-usage  /proc/kcore
> > > Excluding unnecessary pages        : [100.0 %] |
> > > 
> > > Page number of memory in different use
> > > --------------------------------------------------
> > > TYPE			PAGES			EXCLUDABLE	DESCRIPTION
> > > pfn_zero		0x0000000000000000	yes		Pages filled with zero
> > > pfn_cache		0x000000000002b19f	yes		Cache pages
> > > pfn_cache_private	0x0000000000042526	yes		Cache pages + private
> > > pfn_user		0x0000000000026bc3	yes		User process data pages
> > > pfn_free		0x0000000000133f79	yes		Free pages
> > > pfn_hwpoison		0x0000000000000000	yes		Hwpoison pages
> > 
> > Is there a need to display hwpoison pages? I think they are excluded by
> > default. Otherwise reading them might kill makedumpfile process.
> 
> You are right, hwpoison pages are excluded by default. But it truly
> calculated in makedumpfile. I will change it as non-excludable like
> below:
> 
> TYPE			PAGES			EXCLUDABLE	DESCRIPTION
> pfn_hwpoison		0x0000000000000000	No		Hwpoison pages

I think we don't have to display hwpoison pages. It is of no use. Let us
just display the pages which can be excluded using various filtering
levels and total number of pages (without memory hole).

That way people can do some math.

amount of disk space required = total_pages - filtered pages;

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 7/7] add a new interface to show the memory usage of 1st kernel
  2014-07-11 14:46       ` Vivek Goyal
@ 2014-07-14  5:22         ` Baoquan He
  0 siblings, 0 replies; 22+ messages in thread
From: Baoquan He @ 2014-07-14  5:22 UTC (permalink / raw)
  To: Vivek Goyal; +Cc: kexec, kumagai-atsushi

On 07/11/14 at 10:46am, Vivek Goyal wrote:
> On Fri, Jul 11, 2014 at 10:39:45PM +0800, Baoquan He wrote:
> > On 07/11/14 at 10:35am, Vivek Goyal wrote:
> > > On Fri, Jul 11, 2014 at 03:16:04PM +0800, Baoquan He wrote:
> > > > ->$ ./makedumpfile  --mem-usage  /proc/kcore
> > > > Excluding unnecessary pages        : [100.0 %] |
> > > > 
> > > > Page number of memory in different use
> > > > --------------------------------------------------
> > > > TYPE			PAGES			EXCLUDABLE	DESCRIPTION
> > > > pfn_zero		0x0000000000000000	yes		Pages filled with zero
> > > > pfn_cache		0x000000000002b19f	yes		Cache pages
> > > > pfn_cache_private	0x0000000000042526	yes		Cache pages + private
> > > > pfn_user		0x0000000000026bc3	yes		User process data pages
> > > > pfn_free		0x0000000000133f79	yes		Free pages
> > > > pfn_hwpoison		0x0000000000000000	yes		Hwpoison pages
> > > 
> > > Is there a need to display hwpoison pages? I think they are excluded by
> > > default. Otherwise reading them might kill makedumpfile process.
> > 
> > You are right, hwpoison pages are excluded by default. But it truly
> > calculated in makedumpfile. I will change it as non-excludable like
> > below:
> > 
> > TYPE			PAGES			EXCLUDABLE	DESCRIPTION
> > pfn_hwpoison		0x0000000000000000	No		Hwpoison pages
> 
> I think we don't have to display hwpoison pages. It is of no use. Let us
> just display the pages which can be excluded using various filtering
> levels and total number of pages (without memory hole).
> 
> That way people can do some math.
> 
> amount of disk space required = total_pages - filtered pages;

Sounds reasonable! Will change.

> 
> Thanks
> Vivek
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* RE: [PATCH v2] add a new interface to show the memory usage of 1st kernel
  2014-07-11  7:27   ` [PATCH v2] " Baoquan He
@ 2014-07-23  7:20     ` Atsushi Kumagai
  2014-07-23  8:01       ` bhe
  0 siblings, 1 reply; 22+ messages in thread
From: Atsushi Kumagai @ 2014-07-23  7:20 UTC (permalink / raw)
  To: bhe@redhat.com; +Cc: kexec@lists.infradead.org, vgoyal@redhat.com

>@@ -9254,6 +9314,9 @@ main(int argc, char *argv[])
> 		case OPT_DUMP_DMESG:
> 			info->flag_dmesg = 1;
> 			break;
>+		case OPT_MEM_USAGE:
>+                       info->flag_mem_usage = 1;
>+                       break;
> 		case OPT_COMPRESS_SNAPPY:
> 			info->flag_compress = DUMP_DH_COMPRESSED_SNAPPY;
> 			break;
>@@ -9394,6 +9457,18 @@ main(int argc, char *argv[])
>
> 		MSG("\n");
> 		MSG("The dmesg log is saved to %s.\n", info->name_dumpfile);
>+	} else if (info->flag_mem_usage) {
>+		if (!check_param_for_creating_dumpfile(argc, argv)) {
>+			MSG("Commandline parameter is invalid.\n");
>+			MSG("Try `makedumpfile --help' for more information.\n");
>+			goto out;
>+		}

There is no description of this feature, could you add them
into the help message and the man page ?


Thanks
Atsushi Kumagai

>+
>+		if (!show_mem_usage())
>+			goto out;
>+
>+		MSG("\n");
>+		MSG("Showing page number of memory in different use successfully.\n");
> 	} else {
> 		if (!check_param_for_creating_dumpfile(argc, argv)) {
> 			MSG("Commandline parameter is invalid.\n");
>diff --git a/makedumpfile.h b/makedumpfile.h
>index 7ffa1ee..7b537c7 100644
>--- a/makedumpfile.h
>+++ b/makedumpfile.h
>@@ -910,6 +910,7 @@ struct DumpInfo {
> 	int		flag_force;	     /* overwrite existing stuff */
> 	int		flag_exclude_xen_dom;/* exclude Domain-U from xen-kdump */
> 	int             flag_dmesg;          /* dump the dmesg log out of the vmcore file */
>+	int             flag_mem_usage;  /*show the page number of memory in different use*/
> 	int		flag_use_printk_log; /* did we read printk_log symbol name? */
> 	int		flag_nospace;	     /* the flag of "No space on device" error */
> 	int		flag_vmemmap;        /* kernel supports vmemmap address space */
>@@ -1771,6 +1772,7 @@ struct elf_prstatus {
> #define OPT_CYCLIC_BUFFER       OPT_START+11
> #define OPT_EPPIC               OPT_START+12
> #define OPT_NON_MMAP            OPT_START+13
>+#define OPT_MEM_USAGE            OPT_START+14
>
> /*
>  * Function Prototype.
>--
>1.9.3

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* RE: [PATCH 5/7] prepare the dump loads for kcore analysis
  2014-07-11  7:16 ` [PATCH 5/7] prepare the dump loads for kcore analysis Baoquan He
@ 2014-07-23  7:20   ` Atsushi Kumagai
  2014-07-23  8:02     ` bhe
  0 siblings, 1 reply; 22+ messages in thread
From: Atsushi Kumagai @ 2014-07-23  7:20 UTC (permalink / raw)
  To: bhe@redhat.com; +Cc: kexec@lists.infradead.org, vgoyal@redhat.com

>In kcore, only  "System Ram" and "kernel text" program segments
>are needed. And to be more precise, exclude the crashkernel
>memory range.
>
>Signed-off-by: Baoquan He <bhe@redhat.com>

Please fix the compiler warnings below:

warning.c:858: warning: implicit declaration of function ‘is_vmalloc_addr’
warning.c:854: warning: unused variable ‘paddr’


Thanks
Atsushi Kumagai

>---
> elf_info.c | 135 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> elf_info.h |   1 +
> 2 files changed, 136 insertions(+)
>
>diff --git a/elf_info.c b/elf_info.c
>index 1a3e3bd..ca63d34 100644
>--- a/elf_info.c
>+++ b/elf_info.c
>@@ -779,6 +779,141 @@ get_elf_loads(int fd, char *filename)
> 	return TRUE;
> }
>
>+static int exclude_segment(struct pt_load_segment **pt_loads, unsigned int	*num_pt_loads, uint64_t start,
>uint64_t end)
>+{
>+        int i, j, tidx = -1;
>+	unsigned long long	vstart, vend, kvstart, kvend;
>+        struct pt_load_segment temp_seg = {0};
>+	kvstart = (ulong)start | PAGE_OFFSET;
>+	kvend = (ulong)end | PAGE_OFFSET;
>+	unsigned long size;
>+
>+        for (i = 0; i < (*num_pt_loads); i++) {
>+                vstart = (*pt_loads)[i].virt_start;
>+                vend = (*pt_loads)[i].virt_end;
>+                if (kvstart <  vend && kvend > vstart) {
>+                        if (kvstart != vstart && kvend != vend) {
>+				/* Split load segment */
>+				temp_seg.phys_start = end +1;
>+				temp_seg.phys_end = (*pt_loads)[i].phys_end;
>+				temp_seg.virt_start = kvend + 1;
>+				temp_seg.virt_end = vend;
>+				temp_seg.file_offset = (*pt_loads)[i].file_offset + temp_seg.virt_start -
>(*pt_loads)[i].virt_start;
>+
>+				(*pt_loads)[i].virt_end = kvstart - 1;
>+				(*pt_loads)[i].phys_end =  start -1;
>+
>+				tidx = i+1;
>+                        } else if (kvstart != vstart) {
>+				(*pt_loads)[i].phys_end = start - 1;
>+				(*pt_loads)[i].virt_end = kvstart - 1;
>+                        } else {
>+				(*pt_loads)[i].phys_start = end + 1;
>+				(*pt_loads)[i].virt_start = kvend + 1;
>+                        }
>+                }
>+        }
>+        /* Insert split load segment, if any. */
>+	if (tidx >= 0) {
>+		size = (*num_pt_loads + 1) * sizeof((*pt_loads)[0]);
>+		(*pt_loads) = realloc((*pt_loads), size);
>+		if  (!(*pt_loads) ) {
>+		    ERRMSG("Cannot realloc %ld bytes: %s\n",
>+		            size + 0UL, strerror(errno));
>+			exit(1);
>+		}
>+		for (j = (*num_pt_loads - 1); j >= tidx; j--)
>+		        (*pt_loads)[j+1] = (*pt_loads)[j];
>+		(*pt_loads)[tidx] = temp_seg;
>+		(*num_pt_loads)++;
>+        }
>+        return 0;
>+}
>+
>+static int
>+process_dump_load(struct pt_load_segment	*pls)
>+{
>+	unsigned long long paddr;
>+
>+	paddr = vaddr_to_paddr(pls->virt_start);
>+	pls->phys_start  = paddr;
>+	pls->phys_end    = paddr + (pls->virt_end - pls->virt_start);
>+	DEBUG_MSG("process_dump_load\n");
>+	DEBUG_MSG("  phys_start : %llx\n", pls->phys_start);
>+	DEBUG_MSG("  phys_end   : %llx\n", pls->phys_end);
>+	DEBUG_MSG("  virt_start : %llx\n", pls->virt_start);
>+	DEBUG_MSG("  virt_end   : %llx\n", pls->virt_end);
>+
>+	return TRUE;
>+}
>+
>+int get_kcore_dump_loads()
>+{
>+	struct pt_load_segment	*pls;
>+	int i, j, loads=0;
>+	unsigned long long paddr;
>+
>+	for (i = 0; i < num_pt_loads; ++i) {
>+		struct pt_load_segment *p = &pt_loads[i];
>+		if (is_vmalloc_addr(p->virt_start))
>+			continue;
>+		loads++;
>+	}
>+
>+	pls = calloc(sizeof(struct pt_load_segment), loads);
>+	if (pls == NULL) {
>+		ERRMSG("Can't allocate memory for the PT_LOAD. %s\n",
>+		    strerror(errno));
>+		return FALSE;
>+	}
>+
>+	for (i = 0, j=0; i < num_pt_loads; ++i) {
>+		struct pt_load_segment *p = &pt_loads[i];
>+		if (is_vmalloc_addr(p->virt_start))
>+			continue;
>+		if (j >= loads)
>+			return FALSE;
>+
>+		if (j == 0) {
>+			offset_pt_load_memory = p->file_offset;
>+			if (offset_pt_load_memory == 0) {
>+				ERRMSG("Can't get the offset of page data.\n");
>+				return FALSE;
>+			}
>+		}
>+
>+		pls[j] = *p;
>+		process_dump_load(&pls[j]);
>+		j++;
>+	}
>+
>+	free(pt_loads);
>+	pt_loads = pls;
>+	num_pt_loads = loads;
>+
>+	for (i=0; i<crash_reserved_mem_nr; i++)
>+	{
>+		exclude_segment(&pt_loads, &num_pt_loads, crash_reserved_mem[i].start, crash_reserved_mem[i].end);
>+	}
>+
>+	max_file_offset = 0;
>+	for (i = 0; i < num_pt_loads; ++i) {
>+		struct pt_load_segment *p = &pt_loads[i];
>+		max_file_offset = MAX(max_file_offset,
>+				      p->file_offset + p->phys_end - p->phys_start);
>+	}
>+
>+	for (i = 0; i < num_pt_loads; ++i) {
>+		struct pt_load_segment *p = &pt_loads[i];
>+		DEBUG_MSG("LOAD (%d)\n", i);
>+		DEBUG_MSG("  phys_start : %llx\n", p->phys_start);
>+		DEBUG_MSG("  phys_end   : %llx\n", p->phys_end);
>+		DEBUG_MSG("  virt_start : %llx\n", p->virt_start);
>+		DEBUG_MSG("  virt_end   : %llx\n", p->virt_end);
>+	}
>+
>+	return TRUE;
>+}
>
> /*
>  * Get ELF information about /proc/vmcore.
>diff --git a/elf_info.h b/elf_info.h
>index 3ce0138..ba27fdf 100644
>--- a/elf_info.h
>+++ b/elf_info.h
>@@ -46,6 +46,7 @@ int get_elf_info(int fd, char *filename);
> void free_elf_info(void);
> int get_elf_loads(int fd, char *filename);
> int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len);
>+int get_kcore_dump_loads();
>
> int is_elf64_memory(void);
> int is_xen_memory(void);
>--
>1.8.4.2


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH v2] add a new interface to show the memory usage of 1st kernel
  2014-07-23  7:20     ` Atsushi Kumagai
@ 2014-07-23  8:01       ` bhe
  0 siblings, 0 replies; 22+ messages in thread
From: bhe @ 2014-07-23  8:01 UTC (permalink / raw)
  To: Atsushi Kumagai; +Cc: kexec@lists.infradead.org, vgoyal@redhat.com

On 07/23/14 at 07:20am, Atsushi Kumagai wrote:
> >@@ -9254,6 +9314,9 @@ main(int argc, char *argv[])
> > 		case OPT_DUMP_DMESG:
> > 			info->flag_dmesg = 1;
> > 			break;
> >+		case OPT_MEM_USAGE:
> >+                       info->flag_mem_usage = 1;
> >+                       break;
> > 		case OPT_COMPRESS_SNAPPY:
> > 			info->flag_compress = DUMP_DH_COMPRESSED_SNAPPY;
> > 			break;
> >@@ -9394,6 +9457,18 @@ main(int argc, char *argv[])
> >
> > 		MSG("\n");
> > 		MSG("The dmesg log is saved to %s.\n", info->name_dumpfile);
> >+	} else if (info->flag_mem_usage) {
> >+		if (!check_param_for_creating_dumpfile(argc, argv)) {
> >+			MSG("Commandline parameter is invalid.\n");
> >+			MSG("Try `makedumpfile --help' for more information.\n");
> >+			goto out;
> >+		}
> 
> There is no description of this feature, could you add them
> into the help message and the man page ?

Thanks for your review. Will add them.

Thanks
Baoquan

> 
> 
> Thanks
> Atsushi Kumagai
> 
> >+
> >+		if (!show_mem_usage())
> >+			goto out;
> >+
> >+		MSG("\n");
> >+		MSG("Showing page number of memory in different use successfully.\n");
> > 	} else {
> > 		if (!check_param_for_creating_dumpfile(argc, argv)) {
> > 			MSG("Commandline parameter is invalid.\n");
> >diff --git a/makedumpfile.h b/makedumpfile.h
> >index 7ffa1ee..7b537c7 100644
> >--- a/makedumpfile.h
> >+++ b/makedumpfile.h
> >@@ -910,6 +910,7 @@ struct DumpInfo {
> > 	int		flag_force;	     /* overwrite existing stuff */
> > 	int		flag_exclude_xen_dom;/* exclude Domain-U from xen-kdump */
> > 	int             flag_dmesg;          /* dump the dmesg log out of the vmcore file */
> >+	int             flag_mem_usage;  /*show the page number of memory in different use*/
> > 	int		flag_use_printk_log; /* did we read printk_log symbol name? */
> > 	int		flag_nospace;	     /* the flag of "No space on device" error */
> > 	int		flag_vmemmap;        /* kernel supports vmemmap address space */
> >@@ -1771,6 +1772,7 @@ struct elf_prstatus {
> > #define OPT_CYCLIC_BUFFER       OPT_START+11
> > #define OPT_EPPIC               OPT_START+12
> > #define OPT_NON_MMAP            OPT_START+13
> >+#define OPT_MEM_USAGE            OPT_START+14
> >
> > /*
> >  * Function Prototype.
> >--
> >1.9.3
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH 5/7] prepare the dump loads for kcore analysis
  2014-07-23  7:20   ` Atsushi Kumagai
@ 2014-07-23  8:02     ` bhe
  0 siblings, 0 replies; 22+ messages in thread
From: bhe @ 2014-07-23  8:02 UTC (permalink / raw)
  To: Atsushi Kumagai; +Cc: kexec@lists.infradead.org, vgoyal@redhat.com

On 07/23/14 at 07:20am, Atsushi Kumagai wrote:
> >In kcore, only  "System Ram" and "kernel text" program segments
> >are needed. And to be more precise, exclude the crashkernel
> >memory range.
> >
> >Signed-off-by: Baoquan He <bhe@redhat.com>
> 
> Please fix the compiler warnings below:
> 
> warning.c:858: warning: implicit declaration of function ‘is_vmalloc_addr’
> warning.c:854: warning: unused variable ‘paddr’

Will do.

Thanks
Baoquan

> 
> 
> Thanks
> Atsushi Kumagai
> 
> >---
> > elf_info.c | 135 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > elf_info.h |   1 +
> > 2 files changed, 136 insertions(+)
> >
> >diff --git a/elf_info.c b/elf_info.c
> >index 1a3e3bd..ca63d34 100644
> >--- a/elf_info.c
> >+++ b/elf_info.c
> >@@ -779,6 +779,141 @@ get_elf_loads(int fd, char *filename)
> > 	return TRUE;
> > }
> >
> >+static int exclude_segment(struct pt_load_segment **pt_loads, unsigned int	*num_pt_loads, uint64_t start,
> >uint64_t end)
> >+{
> >+        int i, j, tidx = -1;
> >+	unsigned long long	vstart, vend, kvstart, kvend;
> >+        struct pt_load_segment temp_seg = {0};
> >+	kvstart = (ulong)start | PAGE_OFFSET;
> >+	kvend = (ulong)end | PAGE_OFFSET;
> >+	unsigned long size;
> >+
> >+        for (i = 0; i < (*num_pt_loads); i++) {
> >+                vstart = (*pt_loads)[i].virt_start;
> >+                vend = (*pt_loads)[i].virt_end;
> >+                if (kvstart <  vend && kvend > vstart) {
> >+                        if (kvstart != vstart && kvend != vend) {
> >+				/* Split load segment */
> >+				temp_seg.phys_start = end +1;
> >+				temp_seg.phys_end = (*pt_loads)[i].phys_end;
> >+				temp_seg.virt_start = kvend + 1;
> >+				temp_seg.virt_end = vend;
> >+				temp_seg.file_offset = (*pt_loads)[i].file_offset + temp_seg.virt_start -
> >(*pt_loads)[i].virt_start;
> >+
> >+				(*pt_loads)[i].virt_end = kvstart - 1;
> >+				(*pt_loads)[i].phys_end =  start -1;
> >+
> >+				tidx = i+1;
> >+                        } else if (kvstart != vstart) {
> >+				(*pt_loads)[i].phys_end = start - 1;
> >+				(*pt_loads)[i].virt_end = kvstart - 1;
> >+                        } else {
> >+				(*pt_loads)[i].phys_start = end + 1;
> >+				(*pt_loads)[i].virt_start = kvend + 1;
> >+                        }
> >+                }
> >+        }
> >+        /* Insert split load segment, if any. */
> >+	if (tidx >= 0) {
> >+		size = (*num_pt_loads + 1) * sizeof((*pt_loads)[0]);
> >+		(*pt_loads) = realloc((*pt_loads), size);
> >+		if  (!(*pt_loads) ) {
> >+		    ERRMSG("Cannot realloc %ld bytes: %s\n",
> >+		            size + 0UL, strerror(errno));
> >+			exit(1);
> >+		}
> >+		for (j = (*num_pt_loads - 1); j >= tidx; j--)
> >+		        (*pt_loads)[j+1] = (*pt_loads)[j];
> >+		(*pt_loads)[tidx] = temp_seg;
> >+		(*num_pt_loads)++;
> >+        }
> >+        return 0;
> >+}
> >+
> >+static int
> >+process_dump_load(struct pt_load_segment	*pls)
> >+{
> >+	unsigned long long paddr;
> >+
> >+	paddr = vaddr_to_paddr(pls->virt_start);
> >+	pls->phys_start  = paddr;
> >+	pls->phys_end    = paddr + (pls->virt_end - pls->virt_start);
> >+	DEBUG_MSG("process_dump_load\n");
> >+	DEBUG_MSG("  phys_start : %llx\n", pls->phys_start);
> >+	DEBUG_MSG("  phys_end   : %llx\n", pls->phys_end);
> >+	DEBUG_MSG("  virt_start : %llx\n", pls->virt_start);
> >+	DEBUG_MSG("  virt_end   : %llx\n", pls->virt_end);
> >+
> >+	return TRUE;
> >+}
> >+
> >+int get_kcore_dump_loads()
> >+{
> >+	struct pt_load_segment	*pls;
> >+	int i, j, loads=0;
> >+	unsigned long long paddr;
> >+
> >+	for (i = 0; i < num_pt_loads; ++i) {
> >+		struct pt_load_segment *p = &pt_loads[i];
> >+		if (is_vmalloc_addr(p->virt_start))
> >+			continue;
> >+		loads++;
> >+	}
> >+
> >+	pls = calloc(sizeof(struct pt_load_segment), loads);
> >+	if (pls == NULL) {
> >+		ERRMSG("Can't allocate memory for the PT_LOAD. %s\n",
> >+		    strerror(errno));
> >+		return FALSE;
> >+	}
> >+
> >+	for (i = 0, j=0; i < num_pt_loads; ++i) {
> >+		struct pt_load_segment *p = &pt_loads[i];
> >+		if (is_vmalloc_addr(p->virt_start))
> >+			continue;
> >+		if (j >= loads)
> >+			return FALSE;
> >+
> >+		if (j == 0) {
> >+			offset_pt_load_memory = p->file_offset;
> >+			if (offset_pt_load_memory == 0) {
> >+				ERRMSG("Can't get the offset of page data.\n");
> >+				return FALSE;
> >+			}
> >+		}
> >+
> >+		pls[j] = *p;
> >+		process_dump_load(&pls[j]);
> >+		j++;
> >+	}
> >+
> >+	free(pt_loads);
> >+	pt_loads = pls;
> >+	num_pt_loads = loads;
> >+
> >+	for (i=0; i<crash_reserved_mem_nr; i++)
> >+	{
> >+		exclude_segment(&pt_loads, &num_pt_loads, crash_reserved_mem[i].start, crash_reserved_mem[i].end);
> >+	}
> >+
> >+	max_file_offset = 0;
> >+	for (i = 0; i < num_pt_loads; ++i) {
> >+		struct pt_load_segment *p = &pt_loads[i];
> >+		max_file_offset = MAX(max_file_offset,
> >+				      p->file_offset + p->phys_end - p->phys_start);
> >+	}
> >+
> >+	for (i = 0; i < num_pt_loads; ++i) {
> >+		struct pt_load_segment *p = &pt_loads[i];
> >+		DEBUG_MSG("LOAD (%d)\n", i);
> >+		DEBUG_MSG("  phys_start : %llx\n", p->phys_start);
> >+		DEBUG_MSG("  phys_end   : %llx\n", p->phys_end);
> >+		DEBUG_MSG("  virt_start : %llx\n", p->virt_start);
> >+		DEBUG_MSG("  virt_end   : %llx\n", p->virt_end);
> >+	}
> >+
> >+	return TRUE;
> >+}
> >
> > /*
> >  * Get ELF information about /proc/vmcore.
> >diff --git a/elf_info.h b/elf_info.h
> >index 3ce0138..ba27fdf 100644
> >--- a/elf_info.h
> >+++ b/elf_info.h
> >@@ -46,6 +46,7 @@ int get_elf_info(int fd, char *filename);
> > void free_elf_info(void);
> > int get_elf_loads(int fd, char *filename);
> > int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len);
> >+int get_kcore_dump_loads();
> >
> > int is_elf64_memory(void);
> > int is_xen_memory(void);
> >--
> >1.8.4.2
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2014-07-23  8:04 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-07-11  7:15 [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
2014-07-11  7:15 ` [PATCH 2/7] functions to get crashkernel memory range Baoquan He
2014-07-11  7:16 ` [PATCH 3/7] preparation functions for parsing vmcoreinfo Baoquan He
2014-07-11  7:16 ` [PATCH 4/7] set vmcoreinfo for kcore Baoquan He
2014-07-11  7:16 ` [PATCH 5/7] prepare the dump loads for kcore analysis Baoquan He
2014-07-23  7:20   ` Atsushi Kumagai
2014-07-23  8:02     ` bhe
2014-07-11  7:16 ` [PATCH 6/7] implement a function to print the memory usage Baoquan He
2014-07-11  7:16 ` [PATCH 7/7] add a new interface to show the memory usage of 1st kernel Baoquan He
2014-07-11  7:27   ` [PATCH v2] " Baoquan He
2014-07-23  7:20     ` Atsushi Kumagai
2014-07-23  8:01       ` bhe
2014-07-11  7:35   ` [PATCH 7/7] " Baoquan He
2014-07-11 14:26   ` Vivek Goyal
2014-07-11 14:35     ` Baoquan He
2014-07-11 14:44       ` Vivek Goyal
2014-07-11 14:35   ` Vivek Goyal
2014-07-11 14:39     ` Baoquan He
2014-07-11 14:46       ` Vivek Goyal
2014-07-14  5:22         ` Baoquan He
2014-07-11 14:19 ` [PATCH 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Vivek Goyal
2014-07-11 14:28   ` Baoquan He

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox