From: ebiederm@xmission.com (Eric W. Biederman)
To: Tim Bird <tim.bird@am.sony.com>
Cc: Matt Mackall <mpm@selenic.com>,
David VomLehn <dvomlehn@cisco.com>,
"dedekind1@gmail.com" <dedekind1@gmail.com>,
Marco Stornelli <marco.stornelli@gmail.com>,
Simon Kagstrom <simon.kagstrom@netinsight.net>,
"linux-embedded@vger.kernel.org" <linux-embedded@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"dwm2@infradead.org" <dwm2@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"paul.gortmaker@windriver.com" <paul.gortmaker@windriver.com>
Subject: Re: [PATCH, RFC] panic-note: Annotation from user space for panics
Date: Wed, 18 Nov 2009 10:16:28 -0800 [thread overview]
Message-ID: <m1iqd77l6r.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4B043467.8000708@am.sony.com> (Tim Bird's message of "Wed\, 18 Nov 2009 09\:52\:39 -0800")
Tim Bird <tim.bird@am.sony.com> writes:
> Eric W. Biederman wrote:
>> Matt Mackall <mpm@selenic.com> writes:
>>
>>> As much as I like kexec, it loses on memory footprint by about 100x.
>>> It's not appropriate for all use cases, especially things like
>>> consumer-grade wireless access points and phones.
>>
>> In general I agree. The cost of a second kernel and initrd can be
>> prohibitive in the smallest systems, and if you do a crash capture
>> with using a standalone app that is reinventing the wheel.
>>
>> That said. I can happily run kdump with only 16M-20M reserved.
>> So on many systems the cost is affordable.
>
> Understood. On some of my systems, the memory budget for the
> entire system is 10M. On most systems I work with, it is a
> struggle to reserve even 64K for this feature.
crash_kexec is really a glorified jump. It is possible to do a lot in
64K with a standalone application. If reliable capture of kernel
crashes is desirable to an embedded NAND device I expect a semi-general
purpose dedicated application for capturing at least dmesg from the
crashed kernel and write it to a file on a NAND filesystem could be
worth someones time.
On general purpose hardware we use a kernel and an initrd simply to
reduce the development work of supporting everything and the kitchen
sink. My impression is that embedded systems can afford a little more
setup time, and a custom compilation, and that the hardware you would like
to store things too is much more common.
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Tim Bird <tim.bird@am.sony.com>
Cc: Matt Mackall <mpm@selenic.com>,
David VomLehn <dvomlehn@cisco.com>,
"dedekind1\@gmail.com" <dedekind1@gmail.com>,
Marco Stornelli <marco.stornelli@gmail.com>,
Simon Kagstrom <simon.kagstrom@netinsight.net>,
"linux-embedded\@vger.kernel.org"
<linux-embedded@vger.kernel.org>,
"akpm\@linux-foundation.org" <akpm@linux-foundation.org>,
"dwm2\@infradead.org" <dwm2@infradead.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"paul.gortmaker\@windriver.com" <paul.gortmaker@windriver.com>
Subject: Re: [PATCH, RFC] panic-note: Annotation from user space for panics
Date: Wed, 18 Nov 2009 10:16:28 -0800 [thread overview]
Message-ID: <m1iqd77l6r.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4B043467.8000708@am.sony.com> (Tim Bird's message of "Wed\, 18 Nov 2009 09\:52\:39 -0800")
Tim Bird <tim.bird@am.sony.com> writes:
> Eric W. Biederman wrote:
>> Matt Mackall <mpm@selenic.com> writes:
>>
>>> As much as I like kexec, it loses on memory footprint by about 100x.
>>> It's not appropriate for all use cases, especially things like
>>> consumer-grade wireless access points and phones.
>>
>> In general I agree. The cost of a second kernel and initrd can be
>> prohibitive in the smallest systems, and if you do a crash capture
>> with using a standalone app that is reinventing the wheel.
>>
>> That said. I can happily run kdump with only 16M-20M reserved.
>> So on many systems the cost is affordable.
>
> Understood. On some of my systems, the memory budget for the
> entire system is 10M. On most systems I work with, it is a
> struggle to reserve even 64K for this feature.
crash_kexec is really a glorified jump. It is possible to do a lot in
64K with a standalone application. If reliable capture of kernel
crashes is desirable to an embedded NAND device I expect a semi-general
purpose dedicated application for capturing at least dmesg from the
crashed kernel and write it to a file on a NAND filesystem could be
worth someones time.
On general purpose hardware we use a kernel and an initrd simply to
reduce the development work of supporting everything and the kitchen
sink. My impression is that embedded systems can afford a little more
setup time, and a custom compilation, and that the hardware you would like
to store things too is much more common.
Eric
next prev parent reply other threads:[~2009-11-18 18:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-12 2:13 [PATCH, RFC] panic-note: Annotation from user space for panics David VomLehn
2009-11-12 18:00 ` Marco Stornelli
2009-11-12 21:56 ` David VomLehn
2009-11-13 8:10 ` Simon Kagstrom
2009-11-13 11:45 ` Artem Bityutskiy
2009-11-13 11:59 ` Simon Kagstrom
2009-11-13 14:16 ` Artem Bityutskiy
2009-11-14 8:28 ` Marco Stornelli
2009-11-17 8:53 ` Artem Bityutskiy
2009-11-17 12:45 ` Marco Stornelli
2009-11-17 13:10 ` Artem Bityutskiy
2009-11-17 15:45 ` Eric W. Biederman
2009-11-17 23:56 ` David VomLehn
2009-11-18 0:28 ` Eric W. Biederman
2009-11-18 0:53 ` David VomLehn
2009-11-18 9:01 ` Américo Wang
2009-11-18 17:01 ` Eric W. Biederman
2009-11-18 0:56 ` Matt Mackall
2009-11-18 16:07 ` Eric W. Biederman
2009-11-18 17:52 ` Tim Bird
2009-11-18 18:16 ` Eric W. Biederman [this message]
2009-11-18 18:16 ` Eric W. Biederman
2009-11-18 8:26 ` Artem Bityutskiy
2009-11-17 17:53 ` Marco Stornelli
2009-11-12 18:06 ` Matt Mackall
2009-11-12 21:58 ` David VomLehn
2009-11-13 11:35 ` Artem Bityutskiy
2009-11-12 19:50 ` Paul Gortmaker
2009-11-12 22:09 ` David VomLehn
2009-11-13 11:50 ` Shargorodsky Atal (EXT-Teleca/Helsinki)
2009-11-13 11:26 ` Artem Bityutskiy
2009-11-17 9:03 ` Artem Bityutskiy
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=m1iqd77l6r.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=dedekind1@gmail.com \
--cc=dvomlehn@cisco.com \
--cc=dwm2@infradead.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.stornelli@gmail.com \
--cc=mpm@selenic.com \
--cc=paul.gortmaker@windriver.com \
--cc=simon.kagstrom@netinsight.net \
--cc=tim.bird@am.sony.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.