Under 2.6.14 (UML), I have a workload that runs with 64 megs ram and 256 megs
swap space. It completes (albeit swapping like mad) with swappiness at the
default 60, but if I set it to 0 the OOM killer kicks in and the script
aborts.
The workload is basically compiling gcc 4.0.2 with gcc 3.3.2. Now gcc a pig
(hence the reason for feeding it 256 megs of swap space), but twiddling
swappiness shouldn't make the difference between success and failure.
Why does the OOM killer ever trigger when there are _any_ dirty pages queued
up for DMA to an existing local block device? (Or when there is SWAP SPACE
LEFT?) This is memory that will be freed in time, thus the system isn't
guaranteed to hang yet. Don't we only need to trigger the OOM killer if the
alternative is the system hanging?
Rob
P.S. Not only is this repeatable, but I have a script that I run that
downloads the UML and gcc sources, builds UML, and tries to build GCC under
it. I can put this up somewhere if anybody would like to try to reproduce
this themselves...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
