From: "Abhishek Sagar" <sagar.abhishek@gmail.com>
To: "Daniel Spång" <daniel.spang@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Out of memory management in embedded systems
Date: Sun, 30 Sep 2007 01:18:09 +0530 [thread overview]
Message-ID: <863e9df20709291248y6d4b3881j527dd3adbb9f3340@mail.gmail.com> (raw)
In-Reply-To: <cfd9edbf0709281358k3f6307e8h4d2c131378645747@mail.gmail.com>
On 9/29/07, Daniel Spång <daniel.spang@gmail.com> wrote:
> > An embedded system is NOT an ordinary system that happens to
> > boot from flash. An embedded system requires intelligent design.
>
> We might be talking about slightly different systems. I agree that
> systems that are really embedded, in the classic meaning often with
> real time constraints, should be designed as you suggests. But there
> are a lot of other systems that almost actually are ordinary systems
> but with limited memory and often without demand paging.
[snip]
> For those systems I think we need a method to dynamically decrease the
> working set of a process when memory is scarce, and not just accept
> that we "are screwed" and let the OOM killer solve the problem.
In certain cases, I guess it could be a problem in the embedded
environment. Especially while running general purpose applications
with carefully designed real-time tasks. An OOM in such a case is
unacceptable.
The whole problem looks like an extension of page frame reclamation in
user space. If the user application's cache was owned by the kernel
(something like vmsplice with SPLICE_F_GIFT?), and the application
managed it accordingly, then they could probably be brought under the
purview of kernel's memory reclamation. This would mean that
applications wouldn't need to be triggered on low memory, and leave
memory freeing to the kernel (simpler and uniform). Perhaps it is even
possible to do this in the kernel currently somehow...?
--
Abhishek Sagar
-
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2007-09-29 19:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-28 12:55 Daniel Spång
2007-09-28 13:09 ` linux-os (Dick Johnson)
2007-09-28 13:30 ` Daniel Spång
2007-09-28 14:04 ` linux-os (Dick Johnson)
2007-09-28 14:14 ` Daniel Spång
2007-09-28 15:16 ` linux-os (Dick Johnson)
2007-09-28 20:58 ` Daniel Spång
2007-09-29 19:48 ` Abhishek Sagar [this message]
2007-09-28 14:17 ` Rik van Riel
2007-09-28 14:36 ` Eric Dumazet
2007-09-28 15:15 ` Rik van Riel
2007-09-28 23:00 ` Nicholas Miell
2007-09-29 1:59 ` Daniel Phillips
[not found] <98nC1-6aM-9@gated-at.bofh.it>
[not found] ` <98nVg-6QQ-21@gated-at.bofh.it>
[not found] ` <98oeB-7gA-9@gated-at.bofh.it>
[not found] ` <98oHC-8ai-5@gated-at.bofh.it>
[not found] ` <98oRk-8mt-21@gated-at.bofh.it>
[not found] ` <98pNu-1pp-17@gated-at.bofh.it>
2007-09-29 9:15 ` Bodo Eggert
[not found] ` <98v6u-1h1-9@gated-at.bofh.it>
[not found] ` <98Qu9-170-1@gated-at.bofh.it>
2007-10-01 7:58 ` Markku Savela
2007-10-01 8:13 ` Bernd Eckenfels
2007-10-01 16:27 ` david
2007-10-01 20:25 ` Robin Getz
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=863e9df20709291248y6d4b3881j527dd3adbb9f3340@mail.gmail.com \
--to=sagar.abhishek@gmail.com \
--cc=daniel.spang@gmail.com \
--cc=linux-kernel@vger.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
all inboxes | Powered by JetHome®