|
 |
e35838 |
From 3883607bb61b265e9de259722b247075f7710994 Mon Sep 17 00:00:00 2001
|
|
|
e35838 |
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
|
|
|
e35838 |
Date: Mon, 20 Jun 2016 15:00:53 +0900
|
|
|
e35838 |
Subject: [PATCH 2/2] [PATCH 2/2] sadump: fix wrong progress report on sadump
|
|
|
e35838 |
formats
|
|
|
e35838 |
|
|
|
e35838 |
Currently, makedumpfile displays wrong progress report on sadump
|
|
|
e35838 |
formats and could result in "Floating point exception" in the worst
|
|
|
e35838 |
case:
|
|
|
e35838 |
|
|
|
e35838 |
Original pages : 0x0000000000000000
|
|
|
e35838 |
Excluded pages : 0x0000000001f2b44a
|
|
|
e35838 |
Pages filled with zero : 0x0000000000b160b5
|
|
|
e35838 |
Non-private cache pages : 0x0000000000007a7e
|
|
|
e35838 |
Private cache pages : 0x0000000000000431
|
|
|
e35838 |
User process data pages : 0x000000000140d4dc
|
|
|
e35838 |
Free pages : 0x0000000000000000
|
|
|
e35838 |
Hwpoison pages : 0x000000000000000a
|
|
|
e35838 |
Remaining pages : 0xfffffffffe0d4bb6
|
|
|
e35838 |
Floating point exception (core dumped)
|
|
|
e35838 |
|
|
|
e35838 |
This is because on sadump-related formats, the number of memory hole
|
|
|
e35838 |
pages is not counted, the number of original pages becomes 0 and zero
|
|
|
e35838 |
division exception occurs below:
|
|
|
e35838 |
|
|
|
e35838 |
9409void
|
|
|
e35838 |
9410print_report(void)
|
|
|
e35838 |
9411{
|
|
|
e35838 |
9412 mdf_pfn_t pfn_original, pfn_excluded, shrinking;
|
|
|
e35838 |
9413
|
|
|
e35838 |
9414 /*
|
|
|
e35838 |
9415 * /proc/vmcore doesn't contain the memory hole area.
|
|
|
e35838 |
9416 */
|
|
|
e35838 |
9417 pfn_original = info->max_mapnr - pfn_memhole;
|
|
|
e35838 |
9418
|
|
|
e35838 |
9419 pfn_excluded = pfn_zero + pfn_cache + pfn_cache_private
|
|
|
e35838 |
9420 + pfn_user + pfn_free + pfn_hwpoison;
|
|
|
e35838 |
9421 shrinking = (pfn_original - pfn_excluded) * 100;
|
|
|
e35838 |
9422 shrinking = shrinking / pfn_original; <-- Here.
|
|
|
e35838 |
|
|
|
e35838 |
This commit fixes this issue by counting the number of memory hole
|
|
|
e35838 |
pages and so the number of original pages. As a result, makedumpfile
|
|
|
e35838 |
displays correct progress report on sadump formats and doesn't exit
|
|
|
e35838 |
abnormally:
|
|
|
e35838 |
|
|
|
e35838 |
Original pages : 0x0000000001ffaa23
|
|
|
e35838 |
Excluded pages : 0x0000000001f2b44a
|
|
|
e35838 |
Pages filled with zero : 0x0000000000b160b5
|
|
|
e35838 |
Non-private cache pages : 0x0000000000007a7e
|
|
|
e35838 |
Private cache pages : 0x0000000000000431
|
|
|
e35838 |
User process data pages : 0x000000000140d4dc
|
|
|
e35838 |
Free pages : 0x0000000000000000
|
|
|
e35838 |
Hwpoison pages : 0x000000000000000a
|
|
|
e35838 |
Remaining pages : 0x00000000000cf5d9
|
|
|
e35838 |
(The number of pages is reduced to 2%.)
|
|
|
e35838 |
Memory Hole : 0x00000000000a55dd
|
|
|
e35838 |
--------------------------------------------------
|
|
|
e35838 |
Total pages : 0x00000000020a0000
|
|
|
e35838 |
|
|
|
e35838 |
Cache hit: 1570176, miss: 12997082, hit rate: 10.8%
|
|
|
e35838 |
|
|
|
e35838 |
Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
|
|
|
e35838 |
Signed-off-by: Baoquan He <bhe@redhat.com>
|
|
|
e35838 |
---
|
|
|
e35838 |
sadump_info.c | 9 +++++++++
|
|
|
e35838 |
1 file changed, 9 insertions(+)
|
|
|
e35838 |
|
|
|
e35838 |
diff --git a/makedumpfile-1.6.0/sadump_info.c b/makedumpfile-1.6.0/sadump_info.c
|
|
|
e35838 |
index 8716167..5ff5595 100644
|
|
|
e35838 |
--- a/makedumpfile-1.6.0/sadump_info.c
|
|
|
e35838 |
+++ b/makedumpfile-1.6.0/sadump_info.c
|
|
|
e35838 |
@@ -213,6 +213,8 @@ sadump_copy_1st_bitmap_from_memory(void)
|
|
|
e35838 |
char buf[si->sh_memory->block_size];
|
|
|
e35838 |
off_t offset_page;
|
|
|
e35838 |
unsigned long bitmap_offset, bitmap_len;
|
|
|
e35838 |
+ mdf_pfn_t pfn, pfn_bitmap1;
|
|
|
e35838 |
+ extern mdf_pfn_t pfn_memhole;
|
|
|
e35838 |
|
|
|
e35838 |
bitmap_offset = si->sub_hdr_offset + sh->block_size*sh->sub_hdr_size;
|
|
|
e35838 |
bitmap_len = sh->block_size * sh->bitmap_blocks;
|
|
|
e35838 |
@@ -250,6 +252,13 @@ sadump_copy_1st_bitmap_from_memory(void)
|
|
|
e35838 |
offset_page += sizeof(buf);
|
|
|
e35838 |
}
|
|
|
e35838 |
|
|
|
e35838 |
+ pfn_bitmap1 = 0;
|
|
|
e35838 |
+ for (pfn = 0; pfn < info->max_mapnr; ++pfn) {
|
|
|
e35838 |
+ if (sadump_is_ram(pfn))
|
|
|
e35838 |
+ pfn_bitmap1++;
|
|
|
e35838 |
+ }
|
|
|
e35838 |
+ pfn_memhole = info->max_mapnr - pfn_bitmap1;
|
|
|
e35838 |
+
|
|
|
e35838 |
/*
|
|
|
e35838 |
* kdump uses the first 640kB on the 2nd kernel. But both
|
|
|
e35838 |
* bitmaps should reflect the 1st kernel memory situation. We
|
|
|
e35838 |
--
|
|
|
e35838 |
2.5.5
|
|
|
e35838 |
|