From: Mark Hatle <fray@mvista.com>
To: Kent Borg <kentborg@borg.org>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Large initrd and arch/ppc/boot/simple Question
Date: Tue, 01 Jul 2003 17:07:06 -0500 [thread overview]
Message-ID: <3F02060A.8010402@mvista.com> (raw)
In-Reply-To: <20030701175117.G20876@borg.org>
This is based on my past observations, and may not reflect the current
version of 2.4.x.
Yes, you can definatly kill a kernel by asking for too much memory.
This is especially true if you do not have swap enabled, which in my
experience is rather rare on embedded systems. I THINK there is a
mechanism that you can turn off over commit of memory which will allow
you to kill processors requesting the memory that doesn't exist. The
only problem with that is depending on how you do this overcommit
control you have to accoutn for COW pages, and other things that may
blow you out.
The best you can hope for is "Under normal circumstances my system
should use this much memory, I will give it X * 1.5 (or some other
reasonable amount)."
This is something that needs to be worked out between the hardware and
software folks, unfortunatly it rarely seems to be and you get bogus
"This product WILL run under 8MB of ram no matter what requirements...
ohh and did I mention it needs to have 16 MB worth of ramdisk?" heh
So in short, no the kernel shouldn't oops when it runs out of memory.
However what is the "correct" thing to do has been debated many times,
and depending on the application returning ENOMEM may be appropriate,
crashing (to cause a reboot) may be appriopriate or a whole host of
other things like killing off the offending process (or a lower priority
process even). It all comes down to system requirements.
--Mark
Kent Borg wrote:
> Looking more, it seems that we are (at minimum) killing the kernel by
> asking for too much memory. We are seeing whether we can reproduce
> that with a simpler program.
>
> -kb
>
>
> In the meantime, here is some output of and about our crash:
>
> $ size bigapp.strip
> text data bss dec hex filename
> 7465252 97296 401844 7964392 7986e8 bigapp.strip
> $ size /tftpboot/zImage.initrd.elf
> text data bss dec hex filename
> 24896 6856704 12732 6894332 6932fc /tftpboot/zImage.initrd.elf
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2003-07-01 22:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-01 20:29 Large initrd and arch/ppc/boot/simple Question Kent Borg
2003-07-01 20:38 ` Wolfgang Denk
2003-07-01 21:51 ` Kent Borg
2003-07-01 22:07 ` Mark Hatle [this message]
2003-07-02 16:54 ` Kent Borg
2003-07-01 22:12 ` Tom Rini
2003-07-01 22:19 ` Kent Borg
-- strict thread matches above, loose matches on Subject: below --
2003-07-01 20:34 Kerl, John
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=3F02060A.8010402@mvista.com \
--to=fray@mvista.com \
--cc=kentborg@borg.org \
--cc=linuxppc-embedded@lists.linuxppc.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 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.