On Thu, 9 Sep 2010, Dave Hansen wrote: > > 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. > Hmm, could you very that /proc/sys/vm/oom_dump_tasks is set? Perhaps it's getting cleared by something else before you use zram. The sysctl should default to on as of 2.6.36-rc1. > > 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. > Presumably you're not using a large amount of swap, either, or that would be accounted for in oom_score. > Trying this again, I just hung the system instead of OOM'ing straight > away like last time. > with the patch, you should still be calling the oom killer and instead of panicking it will go on a serial killing spree because everything that it wasn't judging as a candidate before (oom_score of 0) now is if it's truly killable (oom_score of 1). The patch is definitely needed for correctness since an oom_score of 0 implies the task is unkillable. We're apparently hanging in the exit path for the oom killed task or something is constantly respawning threads that repeatedly get killed. It appears as though nothing is actually a worthwhile target for the oom killer, however, and this is a bad configuration. > 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. > Agreed, we'll need to address hugepages specifically because they don't get accounted for in rss but do free memory when the task is killed. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
