Hi,
Tzafrir Cohen wrote (23 May 2010 17:44:54 GMT) :
> If there's not even swap, I figure that the OOM killer will spring
> into action. Not sure how it acts with tmpfs, though.
I doubt it. The OOM killer's job is to kill userspace processes when
the system happens to lack memory.
In a situation when the mounted (fixed-size) build tmpfs is too small
to host the needed files, no such thing happens: the scare resource is
not memory in this case, but storage space. This is why I suggested
the build would rather abort with a "no space left" error:
$ sudo mount -t tmpfs tmpfs -o size=16M /tmp/test
$ dd if=/dev/zero of=/tmp/test/file bs=1M
dd: writing `/tmp/test/file': No space left on device
$ echo $?
1
So this tmpfs-is-too-small situation does not seem critical to me: the
build will abort with an understandable error that can easily be fixed
by using a bigger tmpfs.
OTOH, the opposite situation (i.e. tmpfs is too big) seems more
critical to me. I believe there is no protection, either in kernel or
userspace, against {mounting,filling} a tmpfs that does not fit in
memory (swap included). I tried the following: I mounted a 4GB tmpfs
on a system with 1GB physical memory + 2GB swap, and ran dd to fill
a file in it with zeros. The system quickly became totally
unresponsive, and I had to use sysrq shortcuts to reboot it. I guess
in that situation, the OOM killer probably killed any userspace
program it could in order to make room for the tmpfs, which is memory
allocated by the kernel, and thus probably deserves a higher priority.
Care must be taken, then, not to allocate too much space to the build
tmpfs. I'm no low-level system expert though, and I'd be glad to
stand corrected.
Bye,
--
intrigeri <intrig...@boum.org>
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @
https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc
| The impossible just takes a bit longer.
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/85aarpn6em....@boum.org
