A. OOM did not kick in and kill kghostview. Why you may ask? Read on to B.
B. The VM has this need to redistribute cache and buffer so that an OOM
situation doesn't take place until all the ram is basically being used. The
problem is that currently the VM will swap out stuff it isn't using and
without buffer it must read from the drive (which is being used to swap)
which takes more cpu which isn't there because the app is locking the kernel
up trying to allocate memory (see why dbench causes mp3 skips). So what
happens is that the kernel cant swap because the hdd io is being strangled by
the process that's going out of control (kghostview) which means that the VM
is stuck doing this redistribution at a snails pace and the OOM situation
never occurs (or occurs many days later when you've died of starvation).
Leaving you deadlocked on a kernel with a VM that is supposed to conquer this
situation and make it a thing of the past.
So what happens after a few days of uptime is that we see where the VM has
slight weaknesses that magnify over time and aren't aparent on the normal run
of tests done on each new release to decide if it's good or not.
Perhaps if i had not had any swap loaded at all this situation would have
been avoided.
I see this as a pretty serious bug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/