Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: Baoquan He <bhe@redhat.com>
Cc: kumagai-atsushi@mxc.nes.nec.co.jp, kexec@lists.infradead.org
Subject: Add "--mem-usage" support for s390x
Date: Mon, 22 Sep 2014 17:02:47 +0200	[thread overview]
Message-ID: <20140922170247.36774052@holzheu> (raw)
In-Reply-To: <1409541340-2719-1-git-send-email-bhe@redhat.com>

Hello Baoquan,

I looked into your patches and tried to add s390x support.

My naive approach was to just enable the is_vmalloc_addr()
for s390x:

--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -814,13 +814,15 @@ unsigned long long vaddr_to_paddr_ppc(un
 #endif          /* powerpc32 */

 #ifdef __s390x__ /* s390x */
+int is_vmalloc_addr_s390x(ulong vaddr);
 int get_machdep_info_s390x(void);
 unsigned long long vaddr_to_paddr_s390x(unsigned long vaddr);
 #define get_phys_base()        TRUE
 #define get_machdep_info()     get_machdep_info_s390x()
 #define get_versiondep_info()  TRUE
 #define vaddr_to_paddr(X)      vaddr_to_paddr_s390x(X)
-#define is_vmalloc_addr(X)     TRUE
+#define is_vmalloc_addr(X)     is_vmalloc_addr_s390x(X)
 #endif          /* s390x */

 #ifdef __ia64__ /* ia64 */

Unfortunately this does not work and makedumpfile loops.
I assume the reason is that get_kcore_dump_loads() is called
before get_machdep_info_s390x() which sets info->vmalloc_start.

I looked into the x86 code and for me it looks like it should
have the same problem.

Have I overlooked something here? Perhaps you can give me a hint?

For testing on my 1G system I hardcoded is_vmalloc_addr(X) to:

#define is_vmalloc_addr(X) ((X) > (1024 * 1024 * 1024))

Then --mem-usage seems to work:

# makedumpfile --mem-usage /proc/kcore
TYPE            PAGES                   EXCLUDABLE      DESCRIPTION
----------------------------------------------------------------------
ZERO            32014                   yes             Pages filled with zero
CACHE           23264                   yes             Cache pages
CACHE_PRIVATE   11462                   yes             Cache pages + private
USER            5154                    yes             User process pages
FREE            20227                   yes             Free pages
KERN_DATA       36903                   no              Dumpable kernel data 

page size:              4096            
Total pages on system:  129024          
Total size on system:   528482304        Byte

Best Regards
Michael


On Mon,  1 Sep 2014 11:15:32 +0800
Baoquan He <bhe@redhat.com> wrote:

> 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 patchset, 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.
> 
> Previouly, patchset v1 was posted. And patch 7/7 has a change in v2.
> So several changes are made in this v3 post per comments from Vivek
> and Atsushi.
> 
> [patch 2/8] functions to get crashkernel memory range
> v3->v4:
>     In old iomem_for_each_line(), it will call exit(1) if opening iomem
>     failed. Atsushi suggested changing this to be consistent with other
>     return value. So here change all the return value to be nr, then
>     check it outside of iomem_for_each_line, and then decide how to act.
> 
> [patch 3/8] preparation functions for parsing vmcoreinfo
> v1->v3:
>     Since get_kernel_version need be called to get page_offset
>     before initial() in mem_usage code flow, and surely it will be called
>     inside initial() again. Add a static variable to avoid this duplicate
>     calling.
> v3->v4:
>     Check the value of info->kernel_version, just return if it has been
>     assigned to a value. This is suggested by Atsushi, far better than the
>     static variable idea.
>     And replace replace get_versiondep_info_x86_64() with get_versiondep_info
>     in get_page_offset().
> v4->v5:
>     Update the git log.
> 
> [patch 4/8] set vmcoreinfo for kcore
> v3->v4:
>     Change several places error messages which are the same in nearby handling.
> 
> [patch 5/8] prepare the dump loads for kcore analysis
> v1->v3:
>     Fix the compiler warnings.
> v3->v4:
>     Rename is_vmalloc_addr() to is_vmalloc_addr_x86_64() in arch/x86_64.c. And
>     then define is_vmalloc_addr() for all other ARCHs, just set their value to
>     be TRUE except of x86_64.
> 
> [patch 6/8] introduce-a-function-exclude_zero_pages_cyclic
> v3->v4:
>     Newly introduce a function exclude_zero_pages_cyclic(), and call it in
>     get_num_dumpable_cyclic().
> 
>     Besides, a strange thing happened when the new interface was tested on
>     my local AMD machine. It always terminated and printed message:
>     "Program terminated with signal SIGKILL"
>     With gdb, it should be going in readmem() of exclude_zero_pages_cyclic, I
>     still don't know why it happened.
> 
> [patch 7/8] implement a function to print the memory usage
> v1->v3:
>     Adjust the printing content and format of dumpable page numbers per Vivek's
>     comments.
> v3->v6:
>     Slightly adjust the printing format and content.
> 
> [patch 8/8]
> v1->v2:
>     Set info->dump_level=MAX_DUMP_LEVEL, with MAX_DUMP_LEVEL all kinds of
>     memory can be calculated.
> v2->v3:
>     Add the description of this feature into help message and man page.
> v3->v4:
>     Continue adjusting the output message of show_mem_usage calling per
>     Vivek's comments.
> v4->v5:
>     Update the git log.
> v5->v6:
>     Adjust the printing format which is related to dump files previously.
> 
> Baoquan He (8):
>   initialize pfn_memhole in get_num_dumpable_cyclic
>   functions to get crashkernel memory range
>   preparation functions for parsing vmcoreinfo
>   set vmcoreinfo for kcore
>   prepare the dump loads for kcore analysis
>   introduce a function exclude_zero_pages_cyclic()
>   implement a function to print the memory usage
>   add a new interface to show the memory usage of 1st kernel
> 
>  arch/x86_64.c  |   6 +-
>  elf_info.c     | 237 +++++++++++++++++++++++++++++++++++++++++++++++
>  elf_info.h     |   3 +
>  makedumpfile.8 |  17 ++++
>  makedumpfile.c | 285 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>  makedumpfile.h |  17 ++++
>  print_info.c   |   8 ++
>  7 files changed, 569 insertions(+), 4 deletions(-)
> 


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

  parent reply	other threads:[~2014-09-22 15:03 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-01  3:15 [PATCH v6 0/8] add a new interface to show the memory usage of 1st kernel Baoquan He
2014-09-01  3:15 ` [PATCH v6 1/8] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
2014-09-01  3:15 ` [PATCH v6 2/8] functions to get crashkernel memory range Baoquan He
2014-09-01  3:15 ` [PATCH v6 3/8] preparation functions for parsing vmcoreinfo Baoquan He
2014-09-01  3:15 ` [PATCH v6 4/8] set vmcoreinfo for kcore Baoquan He
2014-09-01  3:15 ` [PATCH v6 5/8] prepare the dump loads for kcore analysis Baoquan He
2014-09-01  3:15 ` [PATCH v6 6/8] introduce a function exclude_zero_pages_cyclic() Baoquan He
2014-09-01  3:15 ` [PATCH v6 7/8] implement a function to print the memory usage Baoquan He
2014-09-01  3:15 ` [PATCH v6 8/8] add a new interface to show the memory usage of 1st kernel Baoquan He
2014-09-02 11:52   ` Vivek Goyal
2014-09-02 13:15     ` Baoquan He
2014-09-02 13:24       ` Baoquan He
2014-09-03  8:18         ` Atsushi Kumagai
2014-09-03  8:21           ` bhe
2014-09-02  6:20 ` [PATCH v6 0/8] " Atsushi Kumagai
2014-09-02  6:38   ` bhe
2014-09-22 15:02 ` Michael Holzheu [this message]
2014-09-23  2:40   ` Add "--mem-usage" support for s390x Baoquan He
2014-09-23  2:48     ` Baoquan He
2014-09-23  2:58       ` Baoquan He
2014-09-24 15:19     ` Michael Holzheu
2014-09-25  9:44       ` Baoquan He
2014-09-26  8:10         ` Michael Holzheu
2014-09-26  8:55           ` Baoquan He
2014-09-26  9:14             ` Baoquan He
2014-09-26 11:34             ` Michael Holzheu
2014-09-29  9:04               ` Baoquan He
2014-09-29 13:12                 ` Michael Holzheu
2014-09-29 13:14                 ` [PATCH] makedumpfile: Enable --mem-usage " Michael Holzheu
2014-09-30  9:02                   ` Baoquan He
2014-10-01 16:59                     ` Michael Holzheu
2014-10-09  6:41                       ` Atsushi Kumagai
2014-10-10 12:23                         ` Michael Holzheu
2014-10-14  7:19                           ` Atsushi Kumagai
2014-10-14  7:28                             ` bhe
2014-10-14  7:42                               ` bhe
2014-10-16 12:37                             ` Michael Holzheu
2014-10-23  6:56                               ` Atsushi Kumagai
2014-10-23 10:30                                 ` Michael Holzheu
2014-10-30  1:29                                   ` Atsushi Kumagai
2014-10-30  9:14                                     ` Michael Holzheu
2014-10-31  5:25                                       ` Atsushi Kumagai
2014-10-27  7:57                                 ` bhe
2014-10-27  9:04                                   ` bhe
2014-10-28  4:34                                     ` Atsushi Kumagai
2014-10-28  4:34                                   ` Atsushi Kumagai
2014-10-28  4:46                                     ` bhe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140922170247.36774052@holzheu \
    --to=holzheu@linux.vnet.ibm.com \
    --cc=bhe@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=kumagai-atsushi@mxc.nes.nec.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox