[Systems] Load on treehouse

[Sascha Silbe]

Excerpts from Bernie Innocenti's message of Wed Sep 29 11:09:07 +0200 2010:

> Were you working near the limit of physical memory?

Certainly, which is why I was unsure whether disabling overcommit might
have helped.

> Adding some swap would help this situation by paging out
> rarely used data and thus lowering the pressure on the VM system.

There was almost no disk IO when this happened, only CPU churn.

> If you have twice the physical memory for your working set, this problem
> should never happen.

Iff, yes. But unless you apply carefully tuned memory limits to all
processes there's no guarantee your physical memory will suffice.

> > I usually configure a small swap place, even if just a RAM disk. This
> > allows the OOM to kick in and everything works fine (enough).
> 
> Have you tried posting a reproducible test case to the lkml? Sounds like
> a kernel bug to me.

I definitely consider it a bug. Unfortunately I always have other,
subjectively more important things to do. Some day I'll try to design
a test case, but for now the workaround is easy enough.
Maybe I should add it as dev-love on bugs.sl.o. ;)

> A lot of Linux systems run with no swap at all, including all embedded
> devices and some servers. It would be a shame if this did not work.

It doesn't matter as much on the current / previous generation of
embedded devices as they run only a very limited set of software. It
doesn't matter whether the process gets killed due to OOM or the kernel
goes into a tight loop. To the user, the box just doesn't work anymore
and gets rebooted (or the 24h on-site service called, depending on
whether the box is operated by a home luser or controls the coffee
supply of $BIG_BOSS).

Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://lists.sugarlabs.org/private/systems/attachments/20100929/02f8de36/attachment.pgp