From: Dimitrios Apostolou <jimis@gmx.net>
To: Bernd Petrovitsch <bernd@firmix.at>
Cc: linux-kernel@vger.kernel.org
Subject: Re: swap file over jffs2 partition
Date: Fri, 29 Feb 2008 20:13:20 +0200 [thread overview]
Message-ID: <47C84B40.6000501@gmx.net> (raw)
In-Reply-To: <1204276763.18969.10.camel@tara.firmix.at>
Bernd Petrovitsch wrote:
> On Fre, 2008-02-29 at 04:50 +0200, Dimitrios Apostolou wrote:
>> Hello list,
>>
>> I intend to build a diskless linux system (root over NFS). Because it
>> has 1GB of embedded flash storage, I'm thinking of using this as swap
>> (I've been bitten many times by the problems linux has with *no*
>
> Put more RAM on the hardware and/or reduce the software on it.
> If that means heavily customizing the distribution: Do it.
> If that means you can't run some specific common distribution[0]: Throw
> it out and roll your own minimalistic one with just the tools and
> especially libraries you need.
> We run Linux on embedded hardware all the time without swapspace without
> any problems (related to the "missing" swapspace).
I have been running swapless linux systems a long time ago, but I think
I have had more problems than not. I have tried setting swappiness and
overcommit settings but these don't help much. Let me explain:
When it is not certain that your system will run a specific task and
only that, it is almost certain that sometime you will run out of
memory. For example in the thin client case a user might open too many
windows and fill the RAM with X server pixmaps...
So when the out of memory condition happens the system will start
swapping. And if you have no swap enabled, the system will swap even
harder: it will swap out all mmap'ed read-only memory segments, which
mostly are the executables themselves. And because these will be needed
immediately they will be swapped in immediately afterwards...
This renders the system *unusable* for all cases. Sometimes it even
stops responding to ping... On the other hand if you have a swap
partition then the kernel will choose to swap out other memory segments,
not the executable ones that are so much needed.
>
>> swap...). And to avoid wearing out the flash storage too fast, I 'm
>
> Swapping (and constantly writing logfiles) will wear it out much faster
> than without. Perhaps not at development time but for sure in the field.
That's why I want to do it over a wear-levelling layer. Given that the
partition is large enough it will hopefully take a while to wear it out.
Thanks,
Dimitris
>
> [....]
>
> Bernd
>
> [0]: Which I highly doubt.
next prev parent reply other threads:[~2008-02-29 18:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-29 2:50 swap file over jffs2 partition Dimitrios Apostolou
2008-02-29 8:43 ` Jörn Engel
2008-02-29 17:29 ` Dimitrios Apostolou
2008-02-29 19:57 ` Jörn Engel
2008-02-29 9:19 ` Bernd Petrovitsch
2008-02-29 18:13 ` Dimitrios Apostolou [this message]
2008-03-02 11:55 ` Bernd Petrovitsch
2008-03-02 13:57 ` David Newall
2008-03-03 14:19 ` Bernd Petrovitsch
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=47C84B40.6000501@gmx.net \
--to=jimis@gmx.net \
--cc=bernd@firmix.at \
--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