From: "bhe@redhat.com" <bhe@redhat.com>
To: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"vgoyal@redhat.com" <vgoyal@redhat.com>
Subject: Re: [Patch v3 7/7] add a new interface to show the memory usage of 1st kernel
Date: Tue, 26 Aug 2014 11:22:47 +0800 [thread overview]
Message-ID: <20140826032247.GA6230@dhcp-16-105.nay.redhat.com> (raw)
In-Reply-To: <0910DD04CBD6DE4193FCF86B9C00BE9724F9CA@BPXM01GP.gisp.nec.co.jp>
On 08/26/14 at 02:28am, Atsushi Kumagai wrote:
> >On 08/01/14 at 07:12am, Atsushi Kumagai wrote:
> >> >Page number of memory in different use
> >> >--------------------------------------------------
> >> >TYPE PAGES EXCLUDABLE DESCRIPTION
> >> >ZERO 0 yes Pages filled with zero
> >>
> >> The number of zero pages is always 0 since it isn't counted during
> >> get_num_dumpable_cyclic(). To count it up, we have to read all of the
> >> pages like exclude_zero_pages(), so we need "exclude_zero_pages_cyclic()".
> >> My idea is to call it in get_num_dumpable_cyclic() like:
> >>
> >> for_each_cycle(0, info->max_mapnr, &cycle)
> >> {
> >> if (!exclude_unnecessary_pages_cyclic(&cycle))
> >> return FALSE;
> >>
> >> + if (info->flag_mem_usage)
> >> + exclude_zero_pages_cyclic(&cycle);
> >> +
> >> for(pfn=cycle.start_pfn; pfn<cycle.end_pfn; pfn++)
> >
> >
> >Hi Atsushi,
> >
> >I just introduced a new function exclude_zero_pages_cyclic as you
> >suggested. But it always exited with below message. I don't know what's
> >wrong with this function. Could you help have a look at it?
> >
> >"Program terminated with signal SIGKILL"
>
> Umm, the code looks no problem and it works well at least on my
> machine (x86_64 on KVM), so I have no idea for now.
>
> Can strace and audit help your investigation? They may provide
> some hints (e.g. Who send SIGKILL) for us.
It only happened on a AMD machine with Quad-Core AMD Opteron(tm)
Processor 1352. I tested on my other 2 intel machines, both of them are
OK.
Just now I used strace to check it, and found it's caused by a reading.
It's weird since that page should be inside the System RAM and can be
read. And before this handling hwpoison has been checked. I am wondering
why it happened.
[ ~]$ sudo readelf -l /proc/kcore
Elf file type is CORE (Core file)
Entry point 0x0
There are 13 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
...
This is the load segment where the page reading error happened.
LOAD 0x0000080080001000 0xffff880080000000
0x0000000000000000
0x000000004fee0000 0x000000004fee0000 RWE 1000
...
LOAD 0x00006a0002001000 0xffffea0002000000
0x0000000000000000
0x00000000013fc000 0x00000000013fc000 RWE 1000
LOAD 0x0000080100001000 0xffff880100000000
0x0000000000000000
0x0000000130000000 0x0000000130000000 RWE 1000
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 8799351988224, SEEK_SET) = 8799351988224
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 8799351992320, SEEK_SET) = 8799351992320
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 8799351996416, SEEK_SET) = 8799351996416
read(3,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
4096) = 4096
lseek(3, 8799365541888, SEEK_SET) = 8799365541888
read(3,
"\340\216\274\226f\177\0\0PCD\224f\177\0\0\265\0\0\0\0\0\0\0p\217\274\226f\177\0\0"...,
4096) = 4096
-----------------------------------------
Here it use lseek to position, then try to read, and then reading failed
and raised a SIGKILL.
lseek(3, 8799381360640, SEEK_SET) = 8799381360640
read(3, <unfinished ...>
+++ killed by SIGKILL +++
Killed
>
>
> Thanks
> Atsushi Kumagai
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2014-08-26 3:24 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-28 8:19 [Patch v3 0/7] add a new interface to show the memory usage of 1st kernel Baoquan He
2014-07-28 8:20 ` [Patch v3 1/7] initialize pfn_memhole in get_num_dumpable_cyclic Baoquan He
2014-07-28 8:20 ` [Patch v3 2/7] functions to get crashkernel memory range Baoquan He
2014-08-01 7:32 ` Atsushi Kumagai
2014-08-12 9:25 ` bhe
2014-07-28 8:20 ` [Patch v3 3/7] preparation functions for parsing vmcoreinfo Baoquan He
2014-08-01 7:12 ` Atsushi Kumagai
2014-08-12 9:46 ` bhe
2014-08-12 10:01 ` bhe
2014-08-14 7:37 ` Atsushi Kumagai
2014-08-14 8:15 ` bhe
2014-07-28 8:20 ` [Patch v3 4/7] set vmcoreinfo for kcore Baoquan He
2014-08-01 7:12 ` Atsushi Kumagai
2014-08-12 10:08 ` bhe
2014-07-28 8:20 ` [Patch v3 5/7] prepare the dump loads for kcore analysis Baoquan He
2014-08-01 7:12 ` Atsushi Kumagai
2014-08-12 10:10 ` bhe
2014-07-28 8:20 ` [Patch v3 6/7] implement a function to print the memory usage Baoquan He
2014-07-28 8:20 ` [Patch v3 7/7] add a new interface to show the memory usage of 1st kernel Baoquan He
2014-07-29 12:43 ` Vivek Goyal
2014-07-31 2:32 ` Baoquan He
2014-08-01 7:12 ` Atsushi Kumagai
2014-08-12 10:14 ` bhe
2014-08-21 10:31 ` bhe
2014-08-26 2:28 ` Atsushi Kumagai
2014-08-26 3:22 ` bhe [this message]
2014-08-26 6:25 ` Petr Tesarik
2014-08-26 14:12 ` bhe
2014-09-02 6:20 ` Atsushi Kumagai
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=20140826032247.GA6230@dhcp-16-105.nay.redhat.com \
--to=bhe@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=kumagai-atsushi@mxc.nes.nec.co.jp \
--cc=vgoyal@redhat.com \
/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