Compiling inside a tmpfs seems to trigger kernel oom killer.

[Shining Arcanine]

I was not sure where to post this, since there are a few forums into which it can go.

Anyway, I am running Gentoo Linux ~amd64 on a system with 4GB of RAM, an 8GB swap partition, and a 8GB tmpfs mounted at /var/tmp/portage. I am using sys-kernel/vanilla-sources-2.6.34. I have noticed that if I compile too many things in parallel, even if the tmpfs is barely utilized, the oom killer seems to activate. This is true with open office where it tends to die with an error message. It also happened last night when I was running emerge --jobs --keep-going -avDuN kde-base/kdeartwork-meta kde-base/kdeadmin-meta kde-base/kdeaccessibility-meta kde-base/kdesdk-meta kde-base/kdewebdev-meta kde-base/kdeutils-meta. Some times this issue manifests itself in terms of segmentation faults when compiling.

Does anyone have any idea why this is happening?

Edit: I just ran dd bs=4096 count=2097152 if=/dev/zero of=/var/tmp/portage/zero.bak. The system became extremely unresponsive when I did this and stayed that way until it finished writing. ksysguard was running at the time and seemed to have crashed, but the operation completed without issue, so I am at a loss to explain why unmounting the tmpfs directory tends to fix things.

[BradN]

I'm not sure if tmpfs is able to use swap as a backing store. If it isn't, then 4GB is definitely not enough to hold an openoffice compilation (8GB should be sufficient but I'm not sure), and expect in the neighborhood of additional 800MB RAM consumed at peak (with 1 job on 64 bit). Compiling openoffice 64 bit on 512MB RAM is downright painful for a particular file but it does complete eventually. The fact that your dd test completed (at least if it really stored that much data) seems to suggest swap can be used for tmpfs though...

Running out of memory shouldn't cause things to segfault (rather the OOM killer should kill something to free some memory or kill the process itself), but bad programming to handle resulting errors might.

If this is happening without a significant majority of your RAM being consumed, then it sounds like a kernel bug, but running out of RAM doesn't always have a graceful outcome. I'm not sure how much storage that KDE compilation you did would end up using.

A potentially confounding factor is that I don't think tmpfs allocation is reflected in the +/- buffers/cache line in `free` output, so I'd suggest using df to check the tmpfs size.

[Shining Arcanine]

[BradN]

Just did an edit to my above message while you were posting, but yes in that case it does seem like a bug somewhere.

[Sadako]

From /usr/src/linux/Documentation/filesystems/tmpfs.txt;