On Wed, 18 Jan 2012 19:41:44 -0800 (PST)
Hugh Dickins [off-list ref] wrote:

On Thu, 19 Jan 2012, KAMEZAWA Hiroyuki wrote:

quoted

On Thu, 19 Jan 2012 07:10:26 +0200
Sasha Levin [off-list ref] wrote:

quoted

Hi all,

During testing, I have triggered the OOM killer by mmap()ing a large block of memory. The OOM kicked in and tried to kill the process:

two questions.

1. What is the kernel version  ?

It says 3.2.0-next-20120119-sasha #128

quoted

2. are you using memcg moutned ?

I notice that, unlike Linus's git, this linux-next still has
mm-isolate-pages-for-immediate-reclaim-on-their-own-lru.patch in.

I think that was well capable of oopsing in mem_cgroup_lru_del_list(),
since it didn't always know which lru a page belongs to.

I'm going to be optimistic and assume that was the cause.

Hmm, because the log hits !memcg at lru "del", the page should be added
to LRU somewhere and the lru must be determined by pc->mem_cgroup.

Once set, pc->mem_cgroup is not cleared, just overwritten. AFAIK, there is
only one chance to set pc->mem_cgroup as NULL... initalization.
I wonder why it hits lru_del() rather than lru_add()...
................

Ahhhh, ok, it seems you are right. the patch has following kinds of codes
==
+static void pagevec_putback_immediate_fn(struct page *page, void *arg)
+{
+       struct zone *zone = page_zone(page);
+
+       if (PageLRU(page)) {
+               enum lru_list lru = page_lru(page);
+               list_move(&page->lru, &zone->lru[lru].list);
+       }
+}
==
..this will bypass mem_cgroup_lru_add(), and we can see bug in lru_del()
rather than lru_add()..

Another question is who pushes pages to LRU before setting pc->mem_cgroup..
Anyway, I think we need to fix memcg to be LRU_IMMEDIATE aware.

Thanks,
-Kmae