From: Baoquan He <bhe@redhat.com>
To: "lizhijian@fujitsu.com" <lizhijian@fujitsu.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"vgoyal@redhat.com" <vgoyal@redhat.com>,
"dyoung@redhat.com" <dyoung@redhat.com>,
"vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"dave.jiang@intel.com" <dave.jiang@intel.com>,
"horms@verge.net.au" <horms@verge.net.au>,
"k-hagio-ab@nec.com" <k-hagio-ab@nec.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>,
"yangx.jy@fujitsu.com" <yangx.jy@fujitsu.com>,
"ruansy.fnst@fujitsu.com" <ruansy.fnst@fujitsu.com>
Subject: Re: [RFC][nvdimm][crash] pmem memmap dump support
Date: Wed, 1 Mar 2023 16:17:25 +0800 [thread overview]
Message-ID: <Y/8KFYraba1Lsh5f@MiWiFi-R3L-srv> (raw)
In-Reply-To: <777f338f-09cb-d9f4-fe5f-3a6f059e4b02@fujitsu.com>
On 03/01/23 at 06:27am, lizhijian@fujitsu.com wrote:
......
> Hi Baoquan
>
> Greatly appreciate your feedback.
>
>
> > 1) In kernel side, export info of pmem meta data;
> > 2) in makedumpfile size, add an option to specify if we want to dump
> > pmem meta data; An option or in dump level?
>
> Yes, I'm working on these 2 step.
>
> > 3) In glue script, detect and warn if pmem data is in pmem and wanted,
> > and dump target is the same pmem.
> >
>
> The 'glue script' means the scirpt like '/usr/bin/kdump.sh' in 2nd kernel? That would be an option,
> Shall we abort this dump if "pmem data is in pmem and wanted, and dump target is the same pmem" ?
Guess you are saying scripts in RHEL/centos/fedora, and yes if I guess
righ. Other distros could have different scripts. For kdump, we need
load kdump kernel/initramfs in advance, then wait to capture any crash.
When we load, we can detect and check whether the environment and
setup is expected. If not, we can warn or error out message to users.
We don't need to do the checking until crash is triggered, then decide
to abort the dump or not.
> > Does this work for you?
> >
> > Not sure if above items are all do-able. As for parking pmem device
> > till in kdump kernel, I believe intel pmem expert know how to achieve
> > that. If there's no way to park pmem during kdump jumping, case D) is
> > daydream.
>
> What's "kdump jumping" timing here ?
> A. 1st kernel crashed and jumping to 2nd kernel or
> B. 2nd/kdump kernel do the dump operation.
>
> In my understanding, dumping application(makedumpfile) in kdump kernel will do the dump operation
> after modules loaded. Does "parking pmem" mean to postpone pmem modules loading until dump
> operation finished ? if so, i think it has the same effect with disabling pmem device in kdump kernel.
I used parking which should be wrong. When crash happened, we currently
only shutdown unrelated CPU and interupt controller, but keep other
devices on-flight. This is why we can preserve the content of crash-ed
kernel's memory. For normal memory device, we reserve small part as
crashkernel to run kdump kernel and dumping, keep the 1st kernel's
memory untouched. For pmem, we may need to do something similar to keep
its content untouched. I am not sure if disabling pmem device is the
thing we need do in kdump kernel, what we want is
1) not shutdown pmem in 1st kernel when crash-ed
2) do not re-initialize pmem, at least do not remove its content
1) has been there with the current handling. We need do something to
guarantee 2)? I don't know pmem well, just personal thought.
next prev parent reply other threads:[~2023-03-01 8:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 6:24 lizhijian
2023-02-28 14:03 ` Baoquan He
2023-03-01 6:27 ` lizhijian
2023-03-01 8:17 ` Baoquan He [this message]
2023-03-03 2:27 ` lizhijian
2023-03-03 9:21 ` Baoquan He
2023-03-07 2:05 ` HAGIO KAZUHITO(萩尾 一仁)
2023-03-07 2:49 ` lizhijian
2023-03-07 8:31 ` HAGIO KAZUHITO(萩尾 一仁)
2023-03-17 6:12 ` Dan Williams
2023-03-17 7:30 ` lizhijian
2023-03-17 15:19 ` Dan Williams
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=Y/8KFYraba1Lsh5f@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dyoung@redhat.com \
--cc=horms@verge.net.au \
--cc=k-hagio-ab@nec.com \
--cc=kexec@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=lizhijian@fujitsu.com \
--cc=nvdimm@lists.linux.dev \
--cc=ruansy.fnst@fujitsu.com \
--cc=vgoyal@redhat.com \
--cc=vishal.l.verma@intel.com \
--cc=y-goto@fujitsu.com \
--cc=yangx.jy@fujitsu.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