On Thu, 2010-09-09 at 12:07 -0700, David Rientjes wrote: > On Thu, 9 Sep 2010, Dave Hansen wrote: > > > Hi Nitin, > > > > I've been playing with using zram (from -staging) to back some qemu > > guest memory directly. Basically mmap()'ing the device in instead of > > using anonymous memory. The old code with the backing swap devices > > seemed to work pretty well, but I'm running into a problem with the new > > code. > > > > I have plenty of swap on the system, and I'd been running with compcache > > nicely for a while. But, I went to go tar up (and gzip) a pretty large > > directory in my qemu guest. It panic'd the qemu host system: > > > > [703826.003126] Kernel panic - not syncing: Out of memory and no killable processes... > > [703826.003127] > > [703826.012350] Pid: 25508, comm: cat Not tainted 2.6.36-rc3-00114-g9b9913d #29 > > I'm curious why there are no killable processes on the system; it seems > like the triggering task here, cat, would at least be killable itself. > Could you post the tasklist dump that preceeds this (or, if you've > disabled it try echo 1 > /proc/sys/vm/oom_dump_tasks first)? That was one odd part here. I didn't disable the tasklist dump, and there was none in the dump. > It's possible that if you have enough swap that none of the eligible tasks > actually have non-zero badness scores either because they are being run as > root or because the amount of RAM or swap is sufficiently high such that > (task's rss + swap) / (total rss + swap) is never non-zero. And, since > root tasks have a 3% bonus, it's possible these are all root tasks and no > single task uses more than 3% of rss and swap. It's a 64GB machine with ~30GB of swap and very little RSS. Your hypothesis seems correct. Just grepping through /proc/[0-9]*/oom_score shows nothing other than 0's. Trying this again, I just hung the system instead of OOM'ing straight away like last time. Your patch makes a lot of sense to me in any case where there aren't large-RSS tasks around using memory. That definitely applies here because of the amount in the compcache store and might also apply with ramfs and hugetlbfs. -- Dave -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>