From: Vivek Goyal <vgoyal@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Yinghai Lu <yinghai@kernel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>, WANG Chao <chaowang@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86, kdump: Set crashkernel_low automatically
Date: Mon, 11 Mar 2013 17:03:34 -0400 [thread overview]
Message-ID: <20130311210333.GF14738@redhat.com> (raw)
In-Reply-To: <513E438D.5010303@zytor.com>
On Mon, Mar 11, 2013 at 01:50:21PM -0700, H. Peter Anvin wrote:
> On 03/11/2013 01:45 PM, Vivek Goyal wrote:
> >
> > - Now we use dracut generated initramfs and it has been growing in size.
> > Now systemd has been pulled in too.
> >
>
> And the solution to that isn't obvious?
Sorry, I did not understand what do you mean by above.
If you are suggesting that move away from dracut, it does not work
in practice. Initially we wrote our custom code to generate custom
initramfs, and we were always lagging in terms of what dump targets
can be supported and kept on constantly fixing the issues which had
been taken care of in dracut one way or other. So it was like
maintaining a duplicate initramfs generation tool.
So we do not want to use non-standard tools just for kdump. dracut
generates the initramfs for first kernel and then it should be able
to for second kernel too.
Another problem is that other user space component developers, they don't
know that they are supposed to work with 64MB in total too. Same is true for
anybody who is writing driver code.
And bloated memory usage is detected, after the fact. After that one
can keep on chasing people, and they say that it is their feature
requirement. And it is not possible to go and optimize every subsystem
so that together they can boot and work with 64MB.
>
> > - makdumpfile needs more memory to dump large machines.
> >
> > There are so many places where memory usage is going up and trying
> > to keep track of all that has been very hard.
>
> Seriously, in particular the O(n) memory requirements you may want to
> think very very hard about.
Well we now also have a mode in makedumpfile where memory requirement is
O(1). Just that it takes more cpu and takes much longer to dump. May be it
can be improved further.
I am more worried about kernel drivers, and all the user space we need
to pull in to initramfs to meet more advanced requirements in kdump
environment.
Thanks
Vivek
next prev parent reply other threads:[~2013-03-11 21:03 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-08 5:54 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer WANG Chao
2013-03-08 6:03 ` CAI Qian
2013-03-08 6:32 ` Yinghai Lu
2013-03-08 6:36 ` Yinghai Lu
2013-03-08 7:20 ` WANG Chao
2013-03-08 7:27 ` Yinghai Lu
2013-03-08 7:33 ` WANG Chao
2013-03-08 7:50 ` Yinghai Lu
2013-03-08 12:12 ` WANG Chao
2013-03-08 18:24 ` Yinghai Lu
2013-03-08 19:39 ` Yinghai Lu
2013-03-11 3:42 ` WANG Chao
2013-03-11 4:56 ` [PATCH] x86, kdump: Set crashkernel_low automatically Yinghai Lu
2013-03-11 14:48 ` Vivek Goyal
2013-03-11 15:02 ` Vivek Goyal
2013-03-11 17:58 ` Yinghai Lu
2013-03-11 18:26 ` Vivek Goyal
2013-03-11 18:44 ` Yinghai Lu
2013-03-11 18:46 ` H. Peter Anvin
2013-03-11 18:50 ` Yinghai Lu
2013-03-11 18:55 ` H. Peter Anvin
2013-03-11 19:06 ` Yinghai Lu
2013-03-11 19:06 ` H. Peter Anvin
2013-03-11 19:08 ` Yinghai Lu
2013-03-11 19:20 ` Vivek Goyal
2013-03-11 19:55 ` H. Peter Anvin
2013-03-11 20:12 ` Vivek Goyal
2013-03-11 20:19 ` H. Peter Anvin
2013-03-11 20:36 ` H. Peter Anvin
2013-03-11 20:38 ` Eric W. Biederman
2013-03-11 20:42 ` H. Peter Anvin
2013-03-11 21:10 ` Vivek Goyal
2013-03-11 21:13 ` H. Peter Anvin
2013-03-11 20:45 ` Vivek Goyal
2013-03-11 20:50 ` H. Peter Anvin
2013-03-11 21:03 ` Vivek Goyal [this message]
2013-03-11 21:06 ` H. Peter Anvin
2013-03-12 13:46 ` Vivek Goyal
2013-03-12 8:35 ` Ingo Molnar
2013-03-11 20:57 ` Yinghai Lu
2013-03-11 21:06 ` Vivek Goyal
2013-03-11 21:15 ` Yinghai Lu
2013-03-11 19:10 ` Vivek Goyal
2013-03-11 19:34 ` Yinghai Lu
2013-03-11 19:38 ` Vivek Goyal
2013-03-11 19:39 ` Yinghai Lu
2013-03-11 19:44 ` Vivek Goyal
2013-03-11 19:44 ` Yinghai Lu
2013-03-18 14:46 ` Vivek Goyal
2013-03-18 15:33 ` Vivek Goyal
2013-03-18 19:05 ` Yinghai Lu
2013-03-18 19:10 ` H. Peter Anvin
2013-03-18 20:00 ` Vivek Goyal
2013-03-18 21:14 ` H. Peter Anvin
2013-03-18 21:25 ` [PATCH v3] " Yinghai Lu
2013-03-18 22:52 ` H. Peter Anvin
2013-03-18 23:26 ` Yinghai Lu
2013-03-19 0:27 ` H. Peter Anvin
2013-03-19 1:04 ` [PATCH v4] " Yinghai Lu
2013-03-19 13:33 ` Vivek Goyal
2013-03-19 15:05 ` [PATCH v5] " Yinghai Lu
2013-03-20 13:08 ` Vivek Goyal
2013-03-20 15:53 ` Yinghai Lu
2013-03-20 16:03 ` Vivek Goyal
2013-03-20 16:21 ` Yinghai Lu
2013-03-20 16:31 ` Vivek Goyal
2013-03-20 19:22 ` [PATCH] kexec: use Crash kernel for Crash kernel low Yinghai Lu
2013-03-25 19:42 ` Vivek Goyal
2013-03-25 21:50 ` Yinghai Lu
2013-03-26 18:14 ` Vivek Goyal
2013-04-01 13:34 ` Vivek Goyal
2013-04-01 18:33 ` H. Peter Anvin
2013-04-01 19:26 ` Vivek Goyal
2013-04-01 20:47 ` H. Peter Anvin
2013-04-01 21:10 ` Yinghai Lu
2013-04-01 22:02 ` H. Peter Anvin
2013-04-01 22:17 ` Yinghai Lu
2013-04-01 22:20 ` H. Peter Anvin
2013-04-01 22:40 ` Yinghai Lu
2013-04-02 1:11 ` Yinghai Lu
2013-04-02 13:50 ` Vivek Goyal
2013-04-02 14:17 ` Vivek Goyal
2013-04-02 14:50 ` Yinghai Lu
2013-04-02 14:45 ` Yinghai Lu
2013-04-02 14:58 ` Vivek Goyal
2013-04-02 15:44 ` Yinghai Lu
2013-04-02 15:39 ` Vivek Goyal
2013-04-02 15:46 ` Yinghai Lu
2013-04-02 15:50 ` Vivek Goyal
2013-04-02 17:21 ` Yinghai Lu
2013-04-02 13:30 ` Vivek Goyal
2013-03-11 19:14 ` [PATCH] x86, kdump: Set crashkernel_low automatically Eric W. Biederman
2013-03-11 19:22 ` Vivek Goyal
2013-03-11 19:59 ` H. Peter Anvin
2013-03-11 20:17 ` Vivek Goyal
2013-03-11 19:56 ` H. Peter Anvin
2013-03-11 19:02 ` Vivek Goyal
2013-03-11 19:04 ` H. Peter Anvin
2013-03-11 19:17 ` Vivek Goyal
2013-03-11 13:14 ` 3.9-rc1: crash kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer Konrad Rzeszutek Wilk
2013-03-08 7:52 ` Takao Indoh
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=20130311210333.GF14738@redhat.com \
--to=vgoyal@redhat.com \
--cc=chaowang@redhat.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=yinghai@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).