Re: [patch -rc] oom: always return a badness score of non-zero for eligible tasks

Dave Hansen
2010-09-09T19:48:07Z

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